El blog de eLafo

¿Quién no ha tenido nunca esa típica discusión con un colega acerca de cuál es la mejor canción o el mejor grupo de la historia? Por supuesto, nunca se llega a una conclusión: que si The Beatles, que si Queen, que a mí me gusta el metal y como Iron Maiden o los Judas no hay nadie… Habrá incluso quien sostenga que David Bisbal es el mejor cantante de todos los tiempos. Todo es discutible. Algunas posturas son más discutibles que otras, pero son discusiones que siempre gustan son entretenidas.

Si tomáramos el proceso de desarrollo de software y lo destiláramos hasta quedarnos con su esencia, uno podría concluir que éste no consiste en otra cosa sino en capturar un conjunto de requisitos funcionales escritos en leguaje humano y traducirlos a un lenguaje que pueda entender una máquina, la cuál se encargaría de ponerlos en marcha.

Podría también concluir que cada vez que se añade, elimina o modifica un requisito tendriamos un sistema completamente nuevo, independiente del que existiera anteriormente. En cada momento de su historia, el software no sería otra cosa más que el conjunto de requisitos que lo conforman en ese mismo momento traducidos a algún tipo de lenguaje “máquina”.

Podría además asumir que el histórico es irrelevante. Lo que importa es cuáles son los requisitos hoy, independientemente de cuáles fueran ayer. O, dicho de otra forma, desde un punto de vista puramente teórico, cada vez que se introdujera un cambio en las especificaciones del sistema deberíamos ser perfectamente capaces de reconstruirlo desde cero.

Sin embargo, como toda teoría que se precie, ésta tiene sus limitaciones cuando se intenta aplicar en el mundo real®.

Llevo las últimas semanas enfrascado en entender de forma más profunda en qué consiste eso que llamamos calidad. Y más concretamente en qué consiste la calidad del software y cómo podemos aumentar la calidad de un proyecto software.

Éste es el primero de una serie de posts que he decidido empezar a escribir y dice así:

No he encontrado evidencia ahí fuera de que el TDD mejore ni la productividad ni la calidad del desarrollo de software. De hecho creo que no se puede conseguir porque el desarrollo de software es algo tan complejo que no tenemos la capacidad para realizar experimentos fiables.

Normalmente cuando se habla del proceso de contrucción de software se hace de principio a fin, pero esta vez quiero hacerlo al revés: Empezar por el final y así tener en mente desde el primer momento qué queremos construir para, más adelante, ver cómo lo construimos.

Podemos asumir que, en última instancia, lo que estamos haciendo es montar y gestionar un entorno (en concreto el entorno de producción). Aunque para llegar a ello necesitamos montar algún entorno más. Al menos, un entorno de desarrollo nos vendría bien… Así que de esto hablaré en este artículo: ¿qué es un entorno y cómo se define?

Este es el primero de una serie de posts acerca de DevOps. La intención que tengo es la de compartir mi visión de DevOps y de cómo me organizo mentalmente para poner en práctica sus principios.

Estreno blog.

¿Otro blog más? Seguramente sí. Simplemente pretendo compartir aquí las reflexiones que ocupan mi día a día. Posiblemente nada glamurosas ni originales pero sí, al menos para mí, interesantes o útiles.