Qué Vida Ésta

Me he revuelto en mi asiento leyendo un par de posts acerca del Desarrollo de Software o Ingeniería de Software y su control y gestión a propósito de una publicación de Tom DeMarco, un antiguo gurú en esto del Software, que se retracta de la visión sobre la gestión de los proyectos de software que escribió hace muchos años, especialmente en la parte de control y medición.

El Control de Software, dice Tom DeMarco, cuesta dinero y esfuerzo. Para un proyecto de 1 millón de dólares que va a producir 1.1 millones de facturación, el control es importatisimo. Para un proyecto de parecido coste que va a producir 50 millones, el control no es tan importante. Entonces: deberíamos enfocarnos sólo en el segundo tipo de proyectos. No dice que el control y la medición no sean necesarios, pero es cierto que en la mayoría de los proyectos, sobretodo en los mejores, el control, teniendo en cuenta el coste que tiene en todos los sentidos, puede no ser importante.

Es evidente que el control es necesario en el mundo actual, los proyectos de software se integran en el mundo empresarial… pero hay que saber qué hay que controlar, y cuanto menos sea necesario ese control, mejor.

Quizá está en los genes del ser humano querer controlar. O quizá esté en el propio raciocinio el miedo a perder el control de lo que le rodea que se convierte en obsesión en ciertos individuos. Quién no ha visto alguna vez al típico jefazo, normalmente sin idea de software ni intención de tenerla, perdiendo su propio control y blasfemando acerca de los desarrolladores.

Hemos tratado de encapsular los proyectos de software bajo los parámetros clásicos de gestión de proyectos, tiempo, coste y calidad, nos hemos roto la crisma y posiblemente haya sido un error y hayamos perdido el tiempo miserablemente.

Echando la vista atrás, viendo los proyectos en los que he participado y cuáles han sido los más exitosos, me salen una serie de factores básicos comunes que hablan de gente más que de otra cosa:

• Contar con buenos desarrolladores a los que les guste su trabajo, mejorar, aprender, disfrutar de la tecnología.
• Contar con un ambiente en el que haya confianza entre los desarrolladores y la gente de negocio, capaces de comunicarse y entender posiciones.
• Contar con desarrolladores que sean capaces de ver más allá del código, que entiendan los objetivos finales y se impliquen con ellos.
• Contar con gente de negocio que sepan comunicar esos objetivos y ser flexibles a cambios según avance el desarrollo de software, abiertos a encontrar limitaciones y soluciones alternativas.
• Contar con desarrolladores con experiencia, que sepan estimar esfuerzos, expectativas, anticipar problemas, en base muchas veces a “feeling” y experiencias pasadas.
• Contar con gente de negocio que se preocupe por entender la tecnología, con experiencia desde el punto de vista de usuario.

En resumen, se me ocurre que un proyecto de software está destinado al fracaso si:

• El coste y tiempos de desarrollo es crítico para el éxito del proyecto.
• Hay que ahorrar a toda costa, mejor becarios y personal junior a tutiplén que gastarse el presupuesto en gente buena.
• No hay tolerancia a tiempos y margen.
• No hay interés por entender la tecnología.

Realmente el control de software, la predicción precisa y la anticipación del resultado final del producto, es ciencia ficción, como se concluye en el artículo. Siempre tendrá un componente experimental. Algunos de mis profesores de gestión de proyectos, admitían, como hace Tom DeMarco, que a lo mejor han acertado una o dos veces con la planificación de un proyecto en toda su vida (esto se llama casualidad).

Cada día estoy más convencido de que el desarrollo de software se acerca más a un arte. Nunca dos desarrolladores escribirían el mismo código, posiblemente ni parecido. Nunca se acertará en el tiempo ni el coste, y la calidad dependerá más de quién lo hace y las circunstacias del momento. ¿No suena esto a algo artístico?. Ya lo dice el eslogan de WordPress: Code Is Poetry.

De recomendable lecura las reflexiones de Jeff Atwood y Ricardo Galli

Después de pasar media vida con CVS y la otra media con Subversion, hemos dado el paso en Acilia y vamos a utilizar Git como repositorio de código. La verdad es que las referencias eran muy buenas y, aunque el tener que aprender un nuevo sistema siempre es un poco duro, creemos que merece la pena.

El significado de Git en inglés es algo así como persona estúpida y desagradable y fue diseñado inicialmente por Linus Torvalds, que dejó algunas perlas para la historia, como viene siendo habitual en el personaje:

“I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git.” – Linus Torvalds

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source code management system than CVS is” – Linus Torvalds

When I say I hate CVS with passion, I have to also say that if there any SVN users in the audience, you might want to leave. Because my hatredof CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was ’CVS done right’ or something like that. And if you start with that kind of slogan, there is nowhere you can go. It’s like, there is no way to do CVS right. – Linus Torvalds

Lo mejor de Git es que es un repositorio distribuido. O más que distribuido, es deslocalizado. Esto quiere decir que localmente tienes un repositorio de Git totalmente funcional, de hecho los commits se hacen contra tu repositorio local. Luego juntas tu código con otros repositorios (o normalmente un repositorio que todo el mundo usa de referencia).

Además del vídeo donde el amigo Linus hace la presentación, dejo algunos enlaces de referencia. (Gracias Raúl por ellos y animarnos a dar el paso!)

Referencias:

– Git fetch and pull video tutorial

– Tutorial de Git del Gsyc

– Git Cheat Sheet

Para evitar disgustos como le sucedió a ma.gnolia.com (que perdió todos los datos de sus servidores y no pudo recuperarlos), es buena idea tener un sistema de backups al día que te permita recuperarte de cualquier catástrofe. Como decía aquel doctor en la tele, es mejor prevenir que lamentar. Dejo por aquí un pequeño script que puede ayudar a la tarea. Realmente simple pero efectivo.

Los archivos: back_daily.ftp , back_monthly.ftp

Algunos comentarios de las partes que tienen (comentaré el daily):

1. Tomamos la variable DAY con la fecha del sistema

DAY=`date +%d`
echo Backup for Day: $DAY

2. Volcado de todas las bases de datos del sistema

mysqldump -uUSER -pPASSWORD –all-databases > mysql_backups/mysql-latest.sql

3. Zip con archivos y base de datos

zip -r file_backups/files_back_$DAY.zip public_html/*
zip -r file_backups/files_back_$DAY.zip hostx/*
zip -r file_backups/files_back_$DAY.zip hosty/*
zip -r file_backups/files_back_$DAY.zip hostz/*
zip -r file_backups/mysql_back_$DAY.zip mysql_backups/mysql-latest.sql

4. Subimos todo por FTP

ftp -n HOST-DEL-SERVIDOR.com <
user USERNAME PASSWORD
binary
cd target_directory
lcd file_backups
put files_back_$DAY.zip
put mysql_back_$DAY.zip
quit
EOF

5. Creamos un cronjob que ejecute el script (en este caso dos, uno diario y otro menusal) redirigiendo la salida a un log.

05 03 * * * /home/acilia/file_backups/back_daily.ftp >> /home/acilia/file_backups/log/back_daily.ftp.log
05 03 01 * * /home/acilia/file_backups/back_monthly.ftp >> /home/acilia/file_backups/log/back_monthly.ftp.log

Y con esto sería suficiente para tener un respaldo contra catástrofes. Mediante este sistema, guardaríamos las copias diarias durante 1 mes y las copias mensuales durante 12 meses, aunque siempre sería modificable para que no se sobre-escriban los ficheros. En caso de utilizar estos mismos scripts, habría que tener cuidado con los directorios. En este caso se asume que existen (y tienen permiso de escritura) los directorios mysql_backups y file_backups en la raíz del usuario que ejecutará los scripts.

El script es básico y muy mejorable, no estaría de más echarle un ojo al bash y darle algún retoque… cuando tenga un rato ;-)

A pesar de que las circunstancias parecen aconsejar lo contrario, he decidido dar el paso y crear mi propio pequeño negocio con mucha ilusión, a ver qué tal se da esto de salir de la protección que te da trabajar por cuenta ajena y empezar la aventura por cuenta propia. Con estas premisas he fundado Acilia Internet, donde hacemos desarrollos para terceros basados en nuevas tecnologías y tendencias, tratando de que los procesos de desarrollo de software sean lo más eficientes posible. Además quiero aglutinar algunos proyectos propios donde seguir avanzando y poder probar nuevas cosas, como los ya creados Quiniela15 o AulaDigital.

Por ahora la experiencia es más que satisfactoria. Tener que ocuparse y montar muchas cosas en primera persona no ha sido más que una oportunidad para descubrir, investigar y aprender con mucha más intensidad que hasta ahora había experimentado. No puedo más que recomendar la experiencia a quien tenga ganas pero las dudas o los miedos le retengan. Debe ser una decisión meditada, pero es algo en lo que llega un momento que si tienes el gusanillo vas a hacer. La sombra del fracaso está siempre ahí, pero la esperanza de nuevas oportunidades no va a desaparecer nunca tampoco.

El momento es propicio, es totalmente cierto que en tiempos de crisis hay más oportunidades, en este caso tanto de encontrar gente (aunque sigue siendo difícil encontrar profesionales cualificados en esto de Internet), como otros suministros, como agentes que quieren cambiar modelos y formas de actuar. Internet es el medio perfecto para hacerlo y va a haber mucho que hacer en este sentido en los próximos años.

Personalmente ha comenzado una nueva etapa y estamos a vuestra disposición para lo que pueda surgir!

Los resultados de Google no son demasiado buenos si queremos dar una dimensión temporal a las búsquedas. Uno de los factores que más peso tiene en el PageRank es la cantidad y calidad de enlaces entrantes que tiene una página. Normalmente, cuanto más antigua sea la página en cuestión, más enlaces tiene y tiene más posibilidades de salir arriba en los resultados. Aunque este efecto también se ve contrarrestado en el tiempo por el hecho de que los enlaces tienden a perder PageRank, este efecto puede tardar mucho en desaparecer dependiendo de la búsqueda. Por lo tanto, para ciertas búsquedas en las que el peso de la fecha es importante, los resultados de Google no son muy relevantes. Esto sucede, por ejemplo, en búsquedas de inmuebles en alquiler, de nada sirve que en primeras posiciones aparezcan ofertas que tengan mucha relevancia si ya están caducadas.

Para ello hay un pequeño truco, descubierto en el blog de Jesús Encinar, aunque un poco mejor explicado en TusTrucos.com. Se trata de hacer la búsqueda normalmente y luego añadir un parámetro a la url, que limitará los resultados a un periodo de tiempo dependiendo del valor que le demos:

1. &as_qdr=d,  para que parezcan resultados de las últimas 24h

2. &as_qdr=w, de la última semana

3. &as_qdr=m, del último mes.

4. &as_qdr=y, del último año.

Muy útil si buscamos resultados “frescos” más que relevantes.

Netcraft es uno de los sitios que visito esporádicamente desde que estoy en este sector. Desde hace años, lleva dando etadísticas y análisis técnicos del mundo de internet desde un punto de vista absolutamente tecnológico, muy enfocado a Hosting y sistemas.

Por otro lado, el sitio en sí es un poco desastre en cuanto a navegación y a veces es difícil encontrar cosas. Parece que últimamente lo han hecho “algo” mejor y me he topado con una funcionalidad que no había probado: Una toolbar, qué podemos sumar a la de Alexa, Google y Yahoo! para decorar un bonito Firefox lleno de cachibaches. Está diseñada para ser “Anti-Phising”, pero creo que ofrece información bastante interesante alrededor de esto:

• Fecha de inauguración del dominio, podemos saber cuántos años de servicio tiene el dominio en cuestión.
• Ranking, un nuevo dato a sumar a Compete, Alexa y Google Trends. Por cierto, es bastante dispar respecto a los dos últimos.
• Informe del sitio, con datos acerca del propietario, DNS y un sorprendenre historial de hostings del dominio.
• Pais de la IP, puede parecer una tontería, pero es útil a nivel SEO
• Proveedor de Hosting, buenísimo cuando tienes que elegir un hosting y ver a quiénes más aloja ese proveedor.

Me ha parecido muy interesante y recomendable. Desde luego, es otra de las barritas que he añadido a mi colección.

Hemos hecho un pequeño ejercicio en Quiniela15 comparando el presupuesto y el resultado de los equipos de Primera División de fútbol. Lo primero que llama la atención es la diferencia de presupuesto de Real Madrid y Barcelona, 345 y 315 millones respectivamente, con el resto. El tercer equipo es el Valencia con 139 y el último es el Sporting…¡con sólo 12!

Destacan por su buena gestión del presupuesto el Málaga y el Sporting, quedando 10 y 6 puestos por encima de su ranking presupuestario respectivamente, y en el lado negativo, destacan el Betis, At. Bilbao y Recreativo, que quedaron 5 puestos por debajo de su ranking.

Cuando puedo, lo pillo o me acuerdo, trato de enganchar algún episodio de Life On Mars. La serie trata de un detective que viaja atrás en el tiempo tras un atropello y “aterriza” en el mismo lugar, con el mismo puesto de detective, pero en los 70. Buscando por ahí he encontrado 3 adaptaciones de la serie, con unas versiones muy peculiares de ese viaje en el tiempo . La serie, ya de paso, recupera música de la época con bastante acierto. En España lo hemos cambiado todo, como no. En vez de viajar a 1973, como en las versiones de la BBC (la original) y la ABC Estadounidense, se viaja a 1977. La música que acompaña al viaje en el tiempo es “Life On Mars” de David Bowie, mientras que en la versión española es “Bohemian Rhapsody”, de Queen. En lo que coinciden las tres es en las chupas de cuero y los picos de la camisa kilométricos.

– La versión de la BBC original:

– La versión de la ABC (La mejor a mi juicio). Hay que avanzar hasta el minuto 5:40 para ver el viaje en el tiempo.

– La versión Española, con un toque local ;-)

Esa es la estrategia de Google, que parece haber tomado por el lado más extremista. Según publica Dirson, el gigante de Internet va a poner en marcha un algoritmo que detectará a los empleados descontentos y tratará de evitar su fuga.

Si bien está claro que los algoritmos ayudan para muchas cosas, ¿no estamos exagerando? Me imagino al empleado de Google pensando si su actitud será valorada correctamente por “El Algoritmo” y qué consecuencias tendrá. ¿Sabrá el Algoritmo de distintas culturas? ¿De rasgos de personalidad? ¿ De circunstancias personales?

Parece que asistimos al  descubrimiento del talón de aquiles de Google y quizá al comienzo de su declive,  no sólo manifestado en noticias extravagantes como esta, también en últimos errores bastante sonados como el de Mangas Verdes, todo Internet como un virus, o las caídas de gmail de este año.

Este vídeo es un gran resumen de errores muy comunes en desarrollo de software. Esta “ciencia” es tan exacta como desconocida por la mayoría. A nadie le cuesta hacerse una idea lo que implica un proyecto que se pueda ver y tocar como , por ejemplo, un edificio y todo el mundo entiende que tiene que haber un plan de proyecto, unos planos sobre los que basarse, profesionales que se dediquen a ello, se entiende la magnitud del proyecto porque es algo que se puede ver y se entiende que hay factores que pueden retrasar este tipo de proyectos así como incrementar su coste.

En desarrollo de software esto, aunque en esencia es lo mismo, no se entiende. Además, los desarrolladores suelen ser los últimos en una cadena que raramente está bien definida. No es frecuente encontrar gente fuera del propio desarrollo que entienda esto. Realmente el desconocimiento y la barrera de entrada que supone aprenderlo, está en el origen de todo.