Libros imprescindibles (I): The Nature of Software Development

Libros imprescindibles

El desarrollo de software, así como el mundo de la informática en general, está repleto de información. En cierto modo, ordenar y transformar esta información es el objetivo final de la ciencia de la computación, pero también es un reto que se encuentra en el día a día del desarrollador profesional. Nuevos lenguajes y herramientas emergen cada poco tiempo, antiguos paradigmas son revisitados, y prometedoras metodologías para ordenar el caos inherente al desarrollo se anuncian a bombo y platillo como la solución última para nuestros problemas más repetidos. Toda esta orgía de información ha encontrado en medios de Internet como los renacidos blogs, Twitter, YouTube y los ya clásicos pero inmortales foros, una vía de transmisión casi sin limites.

Por todo esto puede resultar sorprendente la vigencia del libro como medio para la transmisión del conocimiento en Informática, y sin embargo cualquier desarrollador experimentado es capaz de citar al menos diez lecturas imprescindibles para entender mejor este mundo y, por ende, ser mejor profesional. En esta serie de posts vamos a revisar algunas de las que, a nuestro juicio, son las obras más relevantes en nuestro mundillo. El objetivo no es hacer resúmenes ni traducciones, sino animarte a que te embarques en su lectura. Los libros que aquí revisaremos no suelen traducirse al español, salvo en contadísimas excepciones. Aun así te recomendamos hacer la inversión de tiempo y esfuerzo que puede suponer. Realmente merece la pena. Después, si te apetece, podemos sentarnos y discutirlo.

1.- The Nature of Software Development

Comenzamos esta serie de revisiones de libros sobre desarrollo de software con un ejemplo relativamente moderno: The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece, de Ron Jeffries. Digo que es relativamente moderno porque su fecha de edición es 2015. Forma parte de un conjunto de revisiones sobre el mundo del desarrollo que los padres del manifiesto Agile han venido haciendo en los últimos tiempos. En este caso, el libro nos ofrece una interpretación de Agile y algunas de sus implementaciones y evoluciones bajo un nuevo paraguas: The Natural Way, una forma de desarrollar software cercana a la propia naturaleza de la disciplina.

No se trata de un libro de programación, sino de desarrollo de software. Establecer esta diferencia es importante. La mayor parte de la literatura en Informática, y casi siempre aquella que suele traducirse a nuestra lengua, trata sobre tecnologías concretas. En este libro no encontrarás una línea de código. The Natural Way habla sobre principios y fundamentos. Es sabiduría en estado puro. Se trata de un libro corto (no llega a las 300 páginas), pero que es capaz de cubrir con maestría el proceso completo de desarrollo de forma consistente.

El libro está organizado en dos grandes partes. La primera de ellas, titulada “The Circle of Value”, describe los puntos fundamentales de este camino hacia el desarrollo de calidad, fundamentalmente a través de la entrega de valor temprana y frecuente. Este es un camino hacia la sencillez, pero que no por ello puede considerarse fácil. El autor hace especial hincapié en la necesidad de pensar, quizá la más difícil de las tareas a las que nos enfrentamos. En la segunda parte, “Notes and Essays”, Jeffries deja patente su genuina maestría a través de diferentes artículos tocando algunos de los temas más sensibles.

Primera parte: El círculo del valor

El valor es el eje sobre el que giran todas las argumentaciones sobre el desarrollo de software moderno. En cuanto al valor, Jeffries lo define como aquello que queremos (“value is what we want”). Centrándose en la parte más cercana a la entrega, el valor comienza cuando se entrega el software. No hay mejor forma de valorar y de generar feedback que enseñar el software. Se habla también de entregas en pequeños paquetes, hacer entendible el software a los compañeros no técnicos, y principalmente sobre el desarrollo funcionalidad a funcionalidad. Todos estos temas ya nos suenan de los tiempos de Extreme Programming, pero se encuentran aquí enunciados de una forma más moderna, hilando con evoluciones más recientes en la misma línea, como la entrega continua. El autor es muy hábil uniendo todos estos puntos, lo que consigue ofrecer un valor añadido incluso al lector que ya era conocedor de todos ellos.

“Value starts when we ship the software”

Desarrollar funcionalidad a funcionalidad

Teniendo claro que nada es mejor para entregar valor que enseñar el software, podemos preguntarnos cómo debemos desarrollarlo para optimizar esta premisa. Esto no significa que haya que centrarse en la implementación y dejar de lado procesos como el análisis y el diseño (un error común en muchos equipos poco experimentados con metodologías como Scrum), pero está claro que todas estas fases deben abordarse de forma diferente. Durante los siguientes capítulos de esta primera parte, el libro se centra en el desarrollo funcionalidad a funcionalidad. Se plantea la necesidad de planificar desde el principio múltiples entregas a lo largo del desarrollo. De esta forma se facilita la gestión, la entrega de valor y, por qué no, el propio desarrollo. Cuando los proyectos crecen de esta manera, es más sencillo además adaptarse a los cambios, nos es posible reaccionar a las necesidades cambiantes de negocio y de gestión.

También se aborda la planificación con este planteamiento. Normalmente se prefiere trabajar con un deadline y presupuesto fijos, y poder adaptar el alcance. De esta manera se puede ir decidiendo entrega a entrega qué debe desarrollarse a continuación (normalmente aquello que aporta mayor valor, claro está). Jeffries evita utilizar la terminología típica de Scrum, tan extendida hoy en día. Habla de un Product Champion como la figura clave a la hora de decidir qué se hará a continuación. La planificación, por tanto, se realizará sobre estos incrementos, sobre historias que tenderán a tener tamaños homogéneos. Una vez realizado este proceso unas cuantas veces, esta capacidad para dividir las historias, junto con el “yesterday’s weather” acumulado, hará que los equipos sean capaces de decidir con precisión qué entregarán en cada incremento.

“Planning with stretch goals is destructive”

En cuanto al desarrollo en sí mismo, siguiendo este enfoque, el libro nos hace una serie de recomendaciones, como por ejemplo:

• Aprender a diferenciar entre lo que es clave y lo que sería un buen añadido (nice to have). Hay que aprender a calibrar cuánto debe desarrollarse de cada funcionalidad. En este caso el afán de completar puede ir en contra de la entrega de valor. Es mucho más seguro desarrollar la funcionalidad de la manera más simple primero, para poder recibir feedback rápidamente.
• Intentar tener siempre el software libre de defectos, en cada entrega. No es bueno dejar fallos colgando, ya que retrasarán el siguiente desarrollo.
• Mantener un esfuerzo de desarrollo equilibrado. No es bueno hacer “sobreingeniería”, como tampoco lo es obviar el diseño. Cada entrega tendrá asociado un esfuerzo necesario en este sentido, y aprenderemos a calibrarlo poco a poco.
• El software debe tener unos fundamentos de arquitectura robustos, sobre todo cuando se quieren desarrollar funcionalidades en paralelo.
• La arquitectura evolucionará a lo largo del desarrollo de software. Si diseñamos demasiado “up-front” seguro que acabamos haciendo demasiado, y consumiendo recursos que deberían ser invertidos en desarrollo.

No se olvida el autor de la excelencia técnica. No es una sorpresa, dada su experiencia. Este es un punto importante sobre el que varios de los padres de Agile (como Martin Fowler o Uncle Bob, de forma más sonora) han venido poniendo el acento últimamente. En este caso también hace recomendaciones, siempre con la nota añadida de “condición sine qua non”. Las más relevantes se podrían resumir en los siguientes puntos:

• Además de los tests de desarrollador (o tests unitarios), deben construirse test a nivel de negocio para cada funcionalidad para la que sea posible. La mejor manera de conseguir esto es expresar las funcionalidades en base a los tests que estas deben pasar. Las suites de tests deben estar automatizadas y poder ejecutarse rápidamente.
• Se trabaja incrementalmente, por lo que se necesita un buen diseño, pero sólo suficientemente necesario. Eso sí, debe tratarse de un diseño de alta calidad en todo momento.
• La refactorización va de la mano del testing en el desarrollo incremental. Debe ser parte del proceso natural de construir software. No se ha encontrado una manera mejor de hacerlo.

“Bad work is hard to see. We can’t see it from the outside: it’s under the surface”

En resumen: Las funcionalidades nos ayudan a entregar valor. Entregarlas pronto nos ofrece valor temprano, y este enfoque de desarrollo también facilita la gestión. Se simplifica el proceso de planificación. Construir el software en base a funcionalidades de manera incremental hace que entreguemos un producto completo cada poco tiempo (se suele hablar de dos semanas). Estas deben ser funcionalidades completas, aunque simples, libres de errores.

Segunda parte: Notas y ensayos

En esta segunda parte el autor nos regala una serie de artículos que abordan los puntos más relevantes del enfoque propuesto de manera muy elocuente. Entre estos temas se encuentran el valor (por supuesto), la composición de equipos, la dificultad de aplicar estos principios, el problema de la estimación, la gestión, la mejora y el aprendizaje continuos, y las metodologías basadas en Agile. No haré un resumen de todos estos ensayos, aunque recomiendo encarecidamente su lectura, pero sí pongo aquí algunas de las citas que más me han llamado la atención.

• “El valor tiene distintas formas, hay que saber elegir qué es importante para nosotros”
• “No recomiendo utilizar medidas numéricas, con respecto al valor e incluso al coste. Hay unas cuantas razones para esto”
• “Que sea sencillo no quiere decir que sea fácil”
• “El Product Champion decide qué problema solucionar; el equipo decide cómo solucionarlo”
• “Un equipo auto organizado que posea maestría técnica y que entienda su propósito. Ese es el punto dulce”
• “Vas a llegar a entregar en la fecha, no por presionar al equipo, sino gestionando adecuadamente qué hacer y qué dejar para más adelante (o no hacer)”
• “Bajo presión, los equipos prueban menos y dejan defectos en el software. Estos defectos terminan llegando al cliente. El valor se reduce directamente”
• “No fustigues a los ponnies, ayúdales a mejorar”
• “Trabaja en la productividad del equipo por encima de la productividad personal”
• “Al menos, ¿podemos usar la velocidad para estimar cuándo terminaremos? En una palabra: No”
• “La mejor forma de acelerar el desarrollo dentro de un equipo es incrementar la habilidad de sus miembros”
• “Para mantener un progreso constante, necesitamos un diseño claro y limpio siempre. Para esto debemos refactorizar continuamente”
• “Por encima de todo: piensa”

Conclusión

The Nature of Software Development es un libro increíblemente fácil de leer. No es largo, las metáforas y explicaciones son intuitivas y se encuentra plagado de ilustraciones sencillas pero elegantes para decorar los conceptos de los que se habla. Es por todo esto que escribir una obra así no está al alcance de cualquiera. Ron Jeffries es un desarrollador con la experiencia de una vida en los mejores equipos, pero también divulgando y haciendo esfuerzos por hacer crecer la profesión. Sus lecciones son útiles para desarrolladores con todo tipo de experiencia. De hecho es un libro que debería releerse cada cierto tiempo.

He leído algunos comentarios y revisiones que lo tildan de ser un libro demasiado simple, y que no contiene ejemplos de código. Mi opinión es que es ahí precisamente donde radica su virtud. En un tiempo en el que los desarrolladores nos encontramos huérfanos de una guía fuerte, y que demandamos con demasiada frecuencia una figura paternal que nos diga cómo debemos hacer nuestro trabajo, Ron Jeffries nos invita a pensar por nosotros mismos, por doloroso que esto nos pueda parecer. Una obra imprescindible.

“Most of all, think”

El autor

Ron Jeffries es un ingeniero de software estadounidense, conocido por ser uno de los firmantes del Manifiesto Agile, y antes creador de Extreme Programming junto con Kent Beck y Ward Cunningham, en el marco del famoso proyecto de nóminas de Chrysler. Es una de las figuras clave en la historia reciente del desarrollo de software, y programa videojuegos en su tiempo libre. Actualmente está haciendo un Space Invaders, y puedes seguir un diario de desarrollo en su blog ronjeffries.com. Tiene 80 años.