¿Reparar o reescribir el software? Cómo decidirlo

Reescribir es una conclusión, no un punto de partida. La mayoría de los sistemas para los que se propone una reescritura no la necesitan. Necesitan un responsable, un plan de reparación y unos meses de trabajo paciente. Unos pocos sí necesitan reescribirse, y la única manera de distinguirlos es entender primero el sistema.

Por qué se proponen las reescrituras

Las reescrituras rara vez se proponen porque el sistema no tenga arreglo técnico. Se proponen porque nadie en el equipo actual entiende el sistema, y reconstruirlo parece la única manera de recuperar ese conocimiento.

Es una motivación honesta. También es la forma más cara de lograr el objetivo. Una reescritura recrea el conocimiento recreando el software, y todo lo que el sistema antiguo aprendió en años de producción, cada caso límite y cada corrección, hay que volver a aprenderlo.

El segundo motivo habitual es la frustración. Los cambios lentos, los incidentes recurrentes y una tecnología desconocida hacen atractivo empezar de cero. La frustración es real. El remedio suele ser que alguien se responsabilice, no sustituir el sistema.

Qué miramos antes de decidir

No respondemos a la pregunta de reparar o reescribir en la primera reunión. La respondemos después de una revisión que cubre cinco aspectos.

Qué hace el sistema. No lo que dice la documentación ni lo que recuerda el fundador. Lo que hace en producción, para qué usuarios y con qué frecuencia. Muchas reescrituras se dimensionan según un uso imaginado.

Dónde está el riesgo. Qué partes fallan, qué partes nadie toca y qué partes guardan datos que no se pueden perder. El riesgo suele concentrarse en una parte pequeña del código.

Si se puede cambiar con seguridad. ¿Hay una forma de desplegar un cambio y saber que ha funcionado? ¿Hay pruebas, entornos de preproducción, copias de seguridad y marcha atrás? Si no, eso va primero sea cual sea la decisión final, porque una reescritura sin ello es una versión más grande del mismo problema.

Cuánto cuesta mantener la tecnología. Los frameworks y los entornos de ejecución llegan al final de su vida útil. Las facturas de alojamiento crecen. Para algunas tecnologías es difícil contratar personal. Son costos reales, pero medibles, y a menudo menores que los de una reescritura.

Qué necesita el negocio a continuación. Un sistema que necesita tres funciones pequeñas al año tiene requisitos distintos de otro que debe duplicar su capacidad. La decisión de reescribir depende del destino, no solo del estado actual.

Cuándo la respuesta es reparar

Reparar es la respuesta con más frecuencia de la que los equipos esperan. Las señales:

El modelo de datos central es sólido, aunque el código que lo rodea esté desordenado.
Los problemas están concentrados. Dos o tres módulos causan la mayoría de los incidentes.
El sistema está en producción con usuarios reales, y el comportamiento del que dependen está en su mayor parte sin documentar.
La tecnología es antigua pero tiene soporte, o puede actualizarse por etapas.

Reparar significa establecer quién es responsable, añadir una red de seguridad (pruebas alrededor de las partes de riesgo, monitorización, despliegues fiables) y después mejorar el sistema sin sustituirlo, con un cambio acotado cada vez. Los usuarios ven primero estabilidad y después mejoras. No se tira nada hasta que su sustituto ha demostrado funcionar.

Cuándo la respuesta es reescribir

Algunos sistemas sí hay que sustituirlos. Las señales son concretas:

La plataforma no tiene soporte y no se puede actualizar. Un framework sin correcciones de seguridad es una fecha límite.
El modelo de datos no se ajusta a lo que el negocio hace ahora, y cada función choca con él.
El sistema se construyó para una escala o un uso que ya no existen, y la mayor parte es peso muerto.
El costo de entenderlo supera el de especificarlo, algo que ocurre con código generado o muy copiado que no tiene un diseño coherente.

Aun así, reescribimos por partes siempre que podemos. Un sistema nuevo que va asumiendo una responsabilidad cada vez del antiguo mantiene el negocio en marcha y mantiene reversible la decisión.

Una matriz de decisión

Los cinco aspectos de la revisión anterior se reducen a una tabla pequeña. Puntúe cada fila para el sistema que tiene delante; la columna con más marcas es la recomendación, y un solo «sustituir» en la fila de la plataforma prevalece sobre el resto.

Pregunta	Apunta a reparar	Apunta a modernizar sin sustituir	Apunta a reescribir o sustituir
¿La plataforma tiene soporte?	Sí, versiones actuales	Sí, pero varias actualizaciones por detrás	No, y no se puede actualizar
¿El modelo de datos se ajusta al negocio?	Sí	En su mayor parte; algunas estructuras chocan con las funciones nuevas	No; cada función lo rodea
¿Hay una forma segura de cambiarlo?	Sí	En parte; hay pruebas y marcha atrás para algunas partes	No, y añadirlas cuesta más de lo que valen las partes
¿Dónde está el riesgo?	Concentrado en dos o tres módulos	Repartido en una capa que se puede sustituir por separado	En todas partes; no hay un diseño coherente que conservar
¿Cuánto se sigue usando?	La mayor parte	La mayor parte, con zonas muertas que eliminar	Una minoría; el resto atiende casos que ya no existen
¿Qué necesita el negocio a continuación?	Funciones pequeñas y estabilidad	Una capacidad nueva importante sobre los mismos cimientos	Un producto distinto

Reparar es mantenimiento con un plan. Modernizar sin sustituir es nuestro servicio de reparación y modernización. Una reescritura también se hace por partes siempre que podemos, con el sistema antiguo funcionando hasta que cada pieza haya demostrado su valía.

Nuestra postura

Entender el sistema, lograr que sea seguro cambiarlo y después decidir. Los equipos que saltan directamente a la reescritura se saltan la parte en la que aprenden qué están sustituyendo, y ese conocimiento es lo más caro de reconstruir.