Este artículo está basado en una conferencia de 2019 titulada “The economics of software design” de J.B. Rainsberger y que está disponible en Youtube en ver conferencia .
Lo que aquí relato es mi libre interpretación de lo que cuenta Rainsberger, lo digo porque puedo estar equivocada y tergiversar sus palabras. O sea son mis palabras, no las suyas, por si acaso. Es para que no me pase lo mismo que al tipo de la cola del cine en la película “Annie Hall” cuando habla sobre el trabajo de Marshall MacLujan ver escena.
El objetivo de la conferencia es explicar porque son necesarias prácticas ágiles a la hora de desarrollar software. Rainsberger con mucho talento sigue un hilo sólido que explica a desarrolladores y no desarrolladores porqué usar practicas ágiles va a mejorar los sistemas de información.
Rainsberger dice que hay tres asuntos importantes en los que hay que centrar la atención cuando se desarrolla software:
- Las funcionalidades desarrolladas (Features)
- El diseño del software (Design)
- La retroalimentación (Feedback)
Funcionalidades desarrolladas
La refactorización es la piedra angular del desarrollo de código. Esta refactorización facilita mejorar el coste marginal. El coste marginal es un término financiero que se puede definir como el incremento de coste al producir N+1 unidades de determinado producto, respecto al coste de producción de N unidades. Llevando esto al mundo software, se puede traducir en el coste de añadir una nueva funcionalidad o cambiar una funcionalidad ya existente. Es menor de añadir o modificar funcionalidades si el sistema está bien diseñada, es decir no es un galimatías. Los patrocinadores del software (financiero de la empresa u organismo) entienden de costes marginales, los desarrolladores de diseño del software. Entonces, si para tener un mejor coste marginal es necesario refactorizar los promotores entienden que refactorizar es necesario, los desarrolladores ya lo saben. La forma de refactorizar constantemente es utilizar TDD (Test Driven Development).
Diseño del software
Para su exposición Rainsberger utiliza el siguiente gráfico.
Aquí la curva representada por g representa el aumento del coste de seguir modificando un sistema que no se desarrolla con “Diseño Evolutivo”. Inicialmente desarrollar el sistema es menos costoso, pero con el tiempo el coste de mantenerlo se eleva exponencialmente, según Rainsberger siguiendo el comportamiento del interés compuesto según Bernoulli, de hay la formula (1+1/n)ⁿ -> e. Sin embargo la curva representada por f corresponde a los sistemas que se desarrollan con “Diseño Evolutivo” (básicamente empleando TDD), en estos el diseño está mejorando constantemente y eso contribuye a que aunque cada vez el sistema sea más complejo el crecimiento de costes sea mucho más moderado. En términos más vulgares que el galimatías sea menor, aunque la complejidad sea mayor.
También dice Rainsberger que el punto t₀ en el caso de los sistemas que no se desarrollan con "Diseño Evolutivo" es el momento en que económicamente es más rentable tirar el sistema y hacerlo de nuevo. Cómo según él nadie sabe calcular cuando llega ese momento, es mejor trabajar con “diseño evolutivo” para evitar el desastre.
Retroalimentación
En cuanto a la producción del software existe un modelo clásico llamado “En cascada” que implica las fases:
Requisitos -> Análisis-> Diseño-> Codificación -> Pruebas -> Puesta en marcha
En este modelo la retroalimentación se ejecuta demasiado tarde. Esto provoca que la cantidad de re-trabajo suela ser ingente porque cuando algo no se ajusta a lo esperado ya hay mucho que cambiar.
En “XP (eXtreme Programming de 1999)” se expuso que era mejor realizar un ciclo de desarrollo y pruebas constante que pusiera en evidencia si lo que se estaba desarrollando era lo que se necesitaba. XP y a continuación Agile aconsejan prácticas que mejoran la retroalimentación: pequeños ciclos de desarrollo, pruebas unitarias para conocer el estado interno del sistema y pruebas de aceptación para saber si el sistema está de acuerdo con las necesidades del usuario.
Rainsberger expone que las técnicas para llevar esto a cabo son TDD y BDD. También las prácticas de DevOps ayudan a la retroalimentación y facilitan la labor coordinada de los equipos de desarrollo y operaciones.
Conclusiones
Esta conferencia apoya de forma empírica y heurística el desarrollo basado en técnicas ágiles.
No hay fórmulas mágicas, pero desarrollar software no es fácil y yo también estoy convencida de que todas las prácticas ágiles contribuyen a que el mundo del desarrollo de software mejore.
Buenas noticias, eso nos beneficia a todos a los informáticos y a los no informáticos.
