Reescribir software es algo que pensarse bien

Los desarrolladores tenemos una maldición que nos persigue desde tiempos inmemoriales y que nos acosa con sus temidas consecuencias. Esta maldición persigue nuestro código y va añadiendo cambios sin que nos demos cuenta convirtiendo nuestro software en una enorme bola de barro.

Esta bola de barro (de la que obviamente no somos responsables 😂) hace que la complejidad y acoplamiento de nuestro sistema aumente y que cada vez se nos haga más difícil realizar cambios.

Es en este momento desesperado cuando hemos de tomar alguna decisión y se nos presentan dos opciones frente nuestra: arreglar el estropicio o reescribirlo todo.

El coste de reescribir software

Tomar la decisión de reescribir un sistema es algo complicado y algo que no tomar a la ligera. Hay un artículo muy interesante que habla sobre el coste oculto de reescribir software y que destaca que rehacer un sistema es más costoso de lo que uno puede estimar en primer momento.

Primero tenemos el coste que estimamos que tendrá la reescritura. Este coste lo controlamos y podemos saber más o menos por dónde van los tiros.

Después tenemos el coste de alcanzar el desarrollo actual. Normalmente, mientras realizamos la escritura del sistema, el desarrollo no para y se van añadiendo nuevas funcionalidades. Este coste de migración extra es el segundo que debemos tener en cuenta.

Y, por otro lado, tenemos el coste que se nos ha pasado por alto. Todas aquellas funcionalidades que no sabíamos que estaban o de las que no entendíamos del todo su complejidad. Esto añade un coste a la reescritura que hay que tener en cuenta.

El problema es que muchas veces nos quedamos con el primer coste y obviamos los otros dos, los cuales en muchos casos pueden llegar a duplicar el tiempo de desarrollo necesario.

Cosas para tener en cuenta cuando reescribimos software

Por tanto, debemos asumir siempre que tardaremos más de lo que dicen nuestras peores estimaciones, ya que podemos tener cualquier imprevisto o coste oculto que no hayamos analizado bien. Como dice la ley de Hofstadter (parafraseada por mí):

Cualquier desarrollo siempre nos conlleva más tiempo de lo estimado, incluso si para estimarlo hemos tenido en cuenta esta ley.

Por otro lado, podemos tener la buena idea de que cuando reescribamos el código quitar todo aquello que ya no es necesario o ha dejado de usarse. El problema es que identificar esas partes que quizá no son necesarias de migrar es una tarea muy complicada.

Yo aquí siempre recurro al principio de la valla de Chesterton, que viene a decir que no elimines algo hasta que no estés seguro de porque está ahí.

Yo lo ejemplifico con un agricultor que ha comprado unos campos que vienen con una valla a lo largo de la carretera. Tras un par de días de trabajar la tierra y no entender muy bien que hace esa valla ahí decide quitarla. Al día siguiente descubre un rebaño de cabras comiéndose sus lechugas. La valla estaba ahí para evitar que cuando pasase el pastor a primera hora las cabras se diesen un festín con el campo.

Una valla es algo costoso de poner, si estaba ahí era por algo. En software ocurre lo mismo, cualquier parte del código está ahí por algo, hasta que no entiendas por qué no lo elimines.

Cuando reescribir software es necesario

He abierto el artículo poniendo como ejemplo la decisión de reescribir nuestro proyecto cuando se ha convertido en una bola de barro inmensa. Sin embargo, hay más motivos por los que es interesante plantearnos reescribir nuestro proyecto.

• Obsolescencia tecnológica: Si el stack tecnológico actual está obsoleto y ya no recibe soporte, lo que dificulta o imposibilita el mantenimiento y las actualizaciones, una reescritura puede ser necesaria para adoptar tecnologías y estándares modernos. Para no seguir implementando nuestros sistemas en COBOL y FORTRAN.
• Código inmantenible: Cuando la base de código existente se ha vuelto demasiado compleja) dificultando que los desarrolladores la comprendan, modifiquen o extiendan, una reescritura puede mejorar la mantenibilidad y legibilidad.
• Problemas de escalabilidad: Cuando la arquitectura actual no puede manejar una mayor carga o demanda de usuarios y escalar no es viable con el diseño existente, una reescritura para implementar una arquitectura más escalable puede estar justificada. Aunque aquí siempre recomiendo intentar implementar arquitecturas evolutivas que sean capaces de adaptarse a nuevos contextos.
• Nuevos requisitos y funcionalidades: Cuando los requisitos del negocio han cambiado significativamente y el sistema actual no puede adaptarse para soportar nuevas características o flujos de trabajo de manera eficiente, una reescritura puede ser la mejor forma de satisfacer las nuevas necesidades.
• Cumplimiento legal o normativo: Si nuevas leyes o regulaciones requieren cambios en el sistema que son imprácticos de implementar en la base de código existente, una reescritura puede ser la única opción viable para asegurar el cumplimiento.

Al final hay que valorar si una reescritura va a aportarnos un valor diferencial con relación al coste que puede tener. Si el nuevo sistema se va a adaptar mejor a nuestro negocio y a las necesidades de nuestros usuarios reescribir nuestro software es una buena decisión estratégica para tomar.

Conclusiones

En conclusión, la reescritura de software es una decisión estratégica que no debe tomarse a la ligera. Aunque a menudo nos encontramos tentados a empezar de cero para librarnos de una bola de barro que ha ido creciendo con el tiempo, es crucial considerar los costos ocultos y los desafíos inherentes al proceso.

Sin embargo, hay momentos en que reescribir el software se vuelve imperativo. La obsolescencia tecnológica, la dificultad de mantenimiento del código existente, los problemas de escalabilidad, los nuevos requisitos y funcionalidades, y las necesidades de cumplimiento legal o normativo son factores que pueden justificar una reescritura. En estos casos, la reescritura puede no solo resolver problemas actuales, sino también posicionar mejor el sistema para futuras necesidades y tecnologías.

Finalmente, la clave está en evaluar cuidadosamente el valor diferencial que una reescritura puede aportar en relación con su costo. Si el nuevo sistema promete adaptarse mejor al negocio y a las necesidades de los usuarios, la reescritura no solo es una decisión viable, sino estratégica. Al tomar esta decisión, los desarrolladores debemos mantener una visión clara y detallada, asegurando que cada paso se tome con una plena comprensión de sus implicaciones y beneficios potenciales.

Photo by Sandie Clarke on Unsplash