Cuándo un proyecto necesita rescate y cuándo reescritura

En corto. La pregunta no es si el código es feo, es si el sistema todavía sostiene el negocio. Si factura, tiene usuarios y las reglas siguen valiendo, casi siempre conviene rescatarlo. La reescritura se justifica cuando la regla de negocio cambió de raíz o la plataforma ya no recibe actualizaciones de seguridad — y casi siempre sale más cara de lo estimado, porque el sistema viejo tiene años de excepciones que nadie escribió. Hay un punto medio que casi nadie propone: reemplazar de a pedazos, con los dos sistemas conviviendo.

Un sistema que factura, que tiene usuarios y que nadie se anima a tocar es, técnicamente, un sistema exitoso. Feo, quizás. Desactualizado, seguro. Pero exitoso: sobrevivió lo suficiente como para que su ausencia sea un problema.

Ese es el punto de partida de casi toda conversación de rescate. Alguien heredó un proyecto que funciona, no puede modificarlo sin miedo, y le dieron dos presupuestos: uno para arreglarlo y otro para hacerlo de nuevo. El segundo suele sonar más limpio. Casi siempre es el equivocado.

La pregunta no es si el código es feo

El código feo no justifica nada por sí solo. Lo que hay que responder primero es otra cosa: ¿el problema está en cómo está hecho el sistema, o en cómo se lo mantiene?

Es una distinción que cambia el presupuesto por completo. Un sistema que nadie puede volver a poner en marcha porque sólo se arma en la computadora de alguien que ya no está no tiene un problema de diseño: tiene un problema de que nunca se escribió cómo se arma. Un sistema que se cae y nadie sabe por qué no necesita cambiar de tecnología: necesita dejar registro de lo que hace. Un sistema lento en tres pantallas no necesita rehacerse: necesita que alguien mire qué le está pidiendo a la base de datos en esas tres pantallas.

Buena parte de lo que se presenta como «hay que rehacerlo» se resuelve en semanas con trabajo poco vistoso: dejar el proyecto armándose igual en cualquier computadora, actualizar las piezas con agujeros de seguridad conocidos, poner algo que avise cuando falla, y recién ahí mirar el código.

Las señales que apuntan a rescate

Rescatar tiene sentido cuando el sistema todavía hace bien lo que tiene que hacer, y el dolor está alrededor.

• Está funcionando y le entra plata o datos reales. Cada día que el reemplazo no está listo, este sigue trabajando. Ese valor es difícil de igualar.
• La información está bien organizada. Podés tener el peor código encima, pero si lo que el sistema guarda y cómo se relaciona entre sí refleja bien tu negocio, tenés la parte cara ya resuelta.
• El problema es de mantenimiento: no se puede volver a poner en marcha, no hay un lugar donde probar antes, nadie probó nunca si las copias de seguridad sirven, nadie sabe qué versión está andando.
• El problema está acotado. Dos partes del sistema concentran el 80% de las fallas y el resto no molesta a nadie.
• Hay reglas de tu negocio que sólo viven adentro del sistema. Esas condiciones raras que parecen basura suelen ser años de casos excepcionales que alguien resolvió a las tres de la mañana. Borrarlas es empezar a recolectarlas de nuevo, una queja de cliente por vez.

Las señales que sí justifican reescribir

Existen, y son menos de las que se invocan.

• La base sobre la que está hecho ya no existe. Una tecnología que nadie actualiza ni protege, un servicio del que dependés que cerró, una base de datos sin soporte. Acá no es una cuestión de gusto: es riesgo.
• La información está mal organizada de raíz. No un dato de más: una cosa que en realidad eran tres, varios clientes que se resolvieron copiando la base entera una y otra vez, una estructura donde no entra algo que tu negocio hoy necesita todos los días. Eso no se arregla por partes: hay que mover todo igual.
• Cada cambio cuesta más que el anterior. Si cada cosa nueva que pedís tarda más que la anterior incluso después de haber ordenado todo lo demás, el problema es de fondo.
• Cambió el producto, no el código. Si lo que hay que construir es otra cosa y sólo comparte el nombre con lo actual, no estás reescribiendo: estás empezando un producto nuevo. Llamalo por su nombre y presupuestalo como tal.

Por qué la reescritura sale más cara de lo que se estima

El error de cálculo es sistemático y tiene una explicación simple: se estima contra lo que se ve, y lo que se ve es la interfaz.

Un sistema con años encima acumula comportamiento invisible. Conexiones con otros sistemas y qué pasa cuando fallan, archivos que se exportan en un formato exacto porque alguien afuera los usa, permisos que se fueron ajustando de a uno, correcciones de datos que se aplican en silencio, un feriado que se calcula distinto. Nada de eso está documentado y nada de eso aparece en una demo. Aparece cuando el sistema nuevo ya está andando, en forma de llamado de cliente.

Después está el costo que nadie pone en la planilla: durante toda la reescritura, el sistema viejo sigue vivo. Hay que mantenerlo, arreglarle las fallas y muchas veces agregarle cosas, porque el negocio no se congela esperando. Estás pagando dos sistemas y persiguiendo un blanco móvil. Cuanto más larga la reescritura, más se aleja.

Y hay un tercer costo, más difícil de aceptar: el que rehace el sistema suele conocer tu negocio menos que el que escribió el original. La versión nueva es más prolija y sabe menos.

El punto medio que casi nadie propone

Entre rescatar y rehacer hay un camino que funciona bien cuando el sistema es grande: reemplazar por partes, con el original andando.

Se pone algo adelante que decide qué atiende el sistema viejo y qué atiende el nuevo. Se empieza por una parte con bordes claros, se la rehace, se manda la gente para allá y se sigue. El sistema viejo se va vaciando hasta que apagarlo es un trámite. Cada paso se puede deshacer, cada paso te sirve para algo, y en ningún momento hay un día único donde cambia todo y todos rezan.

Cuesta más disciplina que una reescritura de cero, porque exige convivir con lo que querés eliminar. A cambio, elimina el peor escenario: que se acabe la plata y todavía no haya nada funcionando.

Por dónde empezar, en cualquiera de los dos casos

Antes de decidir, hay trabajo que sirve igual y que rara vez se hace:

1. Dejar el proyecto armándose y saliendo a andar igual en cualquier computadora.
2. Poner algo que registre cada error y cuánto tarda cada pantalla, para reemplazar opiniones por datos sobre qué se rompe.
3. Poner pruebas automáticas donde hay plata o datos de clientes, aunque sea a grandes rasgos. Esa red es la que te deja tocar el resto sin miedo.

Con esas tres cosas hechas, la decisión deja de ser una discusión de gustos y pasa a apoyarse en evidencia: ya sabés qué falla, cuánto y dónde. Y con frecuencia pasa algo incómodo para quien ya había decidido rehacer todo: el sistema deja de dar miedo antes de llegar a la parte donde había que reescribirlo.