Lecciones de un proyecto que tuvo que ser reconstruido

Hay un momento en la vida de muchos sistemas de software en que la opción de seguir parchando deja de ser viable. Los cambios que antes tomaban un día ahora toman una semana. Cada funcionalidad nueva rompe dos que ya funcionaban. El equipo técnico advierte que "hay que reescribir esto", y los dueños de la empresa escuchan esa frase con una mezcla de frustración y escepticismo: lo que funcionaba —o al menos funcionaba bastante— ahora hay que tirarlo y empezar de nuevo.

Atravesar una reconstrucción completa de un proyecto de software es una de las experiencias más formativas que puede tener una empresa que depende de la tecnología. No porque sea deseable —no lo es—, sino porque obliga a mirar de frente las decisiones que llevaron a esa situación y a construir sobre cimientos distintos.

Este artículo presenta las lecciones que deja ese proceso: las señales que indican que la reconstrucción es inevitable, las condiciones que deben darse para que sea exitosa, y sobre todo, lo que hay que hacer distinto la segunda vez para no tener que hacerlo una tercera.

Lección 1: La reconstrucción no empieza cuando el código se rompe, sino mucho antes

Cuando una empresa decide reconstruir un sistema, la decisión suele presentarse como un evento puntual: el sistema falló de una manera que no se puede arreglar, o el costo de agregar una funcionalidad nueva es tan alto que rehacer todo parece más barato. Pero la realidad es que la necesidad de reconstruir no aparece de golpe: se acumula durante meses o años a través de decisiones que individualmente parecían razonables.

El patrón es casi siempre el mismo. Se construye una primera versión rápido, con los recursos disponibles, para salir al mercado o para resolver una necesidad urgente. Esa primera versión funciona. Después se le agregan funcionalidades sin detenerse a ordenar lo que ya existe. Después cambia el equipo que la construyó y el nuevo equipo no entiende del todo cómo funciona. Después se integra con otros sistemas de formas que no estaban previstas en el diseño original.

Cada una de esas decisiones, tomada por separado, era defendible en su momento. El problema es que nadie se ocupó de pagar el costo acumulado de esas decisiones. Ese costo acumulado es lo que en la industria se llama deuda técnica, y cuando se vuelve impagable, la reconstrucción es la única salida.

La lección no es que hay que evitar toda deuda técnica —eso no es realista—. La lección es que la deuda técnica, como la financiera, se puede tomar siempre y cuando se tenga un plan para pagarla. Si cada tres o cuatro funcionalidades nuevas no se reserva tiempo para ordenar, limpiar y documentar, la deuda se acumula hasta que la única opción es declarar la quiebra técnica y empezar de cero.

Lección 2: Reconstruir sin cambiar lo que causó el problema es reconstruir para volver a fallar

El error más frecuente en un proyecto de reconstrucción no es técnico: es de diagnóstico. Se asume que el problema era el código —que estaba mal escrito, que usaba tecnologías viejas, que no estaba documentado—, cuando en realidad el código era el síntoma de problemas más profundos.

Esos problemas suelen ser: la empresa nunca definió con claridad qué necesitaba que el sistema hiciera, el alcance del proyecto fue cambiando sin que nadie actualizara las bases, no hubo documentación porque nunca se consideró parte del proyecto, o el sistema fue construido por personas que ya no están y que se llevaron el conocimiento de cómo funciona.

Si la reconstrucción se limita a reescribir el código con una tecnología más moderna pero sin resolver esos problemas de fondo, el resultado va a ser un sistema nuevo que dentro de tres años va a estar en la misma situación que el anterior.

Lección 3: La reconstrucción no es un proyecto técnico: es un proyecto de negocio

Un sistema se reconstruye porque dejó de servir al negocio. El objetivo de la reconstrucción no es tener un código más lindo o una arquitectura más moderna: es tener un sistema que le permita a la empresa hacer lo que necesita hacer hoy y lo que va a necesitar hacer en los próximos años.

Esto implica que la decisión de reconstruir, el alcance de la reconstrucción y la definición de éxito deben ser lideradas por la empresa, no por el equipo técnico. El equipo técnico puede —y debe— definir cómo se reconstruye, pero el qué y el para qué son decisiones de negocio.

Una reconstrucción bien gestionada empieza con una pregunta simple: ¿qué tiene que poder hacer este sistema dentro de tres años que hoy no puede hacer? La respuesta a esa pregunta define el alcance. No se reconstruye para tener lo mismo pero más limpio: se reconstruye para tener una base sobre la cual construir lo que viene.

Para entender mejor cuándo una reconstrucción es la decisión correcta —y cuándo alcanza con una modernización progresiva—, el artículo sobre cuándo conviene reconstruir un producto digital ofrece criterios para evaluar ambas opciones.

Lección 4: No todo hay que reconstruirlo de una vez

La imagen mental de una reconstrucción suele ser un "big bang": se apaga el sistema viejo, se prende el nuevo y todos pasan a usarlo. Esa imagen es tentadora pero casi nunca funciona. Las reconstrucciones exitosas son graduales: se reemplazan partes del sistema de a poco, manteniendo lo que funciona y migrando los datos y los usuarios de forma progresiva.

Reconstruir por partes tiene tres ventajas. Primero, permite que el negocio siga operando mientras se reconstruye —el sistema viejo sigue funcionando para todo lo que todavía no se migró—. Segundo, reduce el riesgo: si una parte de la reconstrucción sale mal, el impacto está acotado a esa parte. Tercero, permite validar que el enfoque nuevo funciona antes de comprometer todo el proyecto.

La reconstrucción gradual requiere una arquitectura que la permita. Hay que diseñar el sistema nuevo de forma que pueda convivir con el viejo durante la transición: compartir la misma base de datos, usar las mismas APIs o al menos tener un mecanismo claro de sincronización. Esto agrega complejidad al diseño inicial, pero es una complejidad que se paga con creces en reducción de riesgo.

Lección 5: La documentación no es opcional la segunda vez

En el proyecto original, la documentación probablemente fue lo primero que se sacrificó cuando los plazos apretaron. En la reconstrucción, la documentación no puede ser opcional, porque la falta de documentación es una de las razones por las que se llegó a necesitar una reconstrucción.

Documentar no significa escribir un manual de mil páginas que nadie va a leer. Significa que cualquier persona que se incorpore al proyecto dentro de dos años pueda entender, en un tiempo razonable, cómo está estructurado el sistema, por qué se tomaron ciertas decisiones de diseño y cómo se ponen en funcionamiento sus distintas partes.

La documentación mínima viable para una reconstrucción incluye: un diagrama de la arquitectura del sistema que muestre cómo se conectan sus componentes, una descripción de los módulos principales y de las decisiones de diseño más importantes, y un manual de instalación y despliegue que permita poner el sistema en funcionamiento en un entorno nuevo.

Lección 6: El conocimiento del sistema viejo es más valioso que cualquier tecnología nueva

Cuando un sistema se reconstruye, la tentación es empezar de cero con un equipo nuevo y tecnologías nuevas, dejando atrás todo lo viejo. Pero el sistema viejo, por mal diseñado que esté, contiene años de conocimiento sobre el negocio: reglas que se fueron agregando para manejar casos particulares, integraciones que resuelven problemas que ya nadie recuerda, lógica que parece innecesaria pero que evita que algo se rompa.

Ese conocimiento no está documentado: está en el código y en la cabeza de las personas que trabajaron en él. Perderlo durante la reconstrucción es uno de los errores más costosos, porque lleva a que el sistema nuevo no contemple situaciones que el viejo sí manejaba y que el negocio da por sentadas.

La forma de preservar ese conocimiento es involucrar en la reconstrucción a al menos una persona que conozca bien el sistema viejo. No para que lo defienda ni para que lo replique, sino para que pueda responder la pregunta más importante durante todo el proceso: "¿cómo manejaba esto el sistema anterior y por qué lo manejaba así?".

Si no hay nadie disponible que conozca el sistema viejo, el artículo sobre cómo retomar un proyecto desarrollado por otro equipo ofrece estrategias para reconstruir el conocimiento desde el código existente y desde la operación del negocio.

Lección 7: Medir el éxito de la reconstrucción con métricas de negocio, no técnicas

El éxito de una reconstrucción no se mide en líneas de código, en cobertura de pruebas ni en la versión del framework que se usó. Se mide en cosas que le importan al negocio: el tiempo que lleva agregar una funcionalidad nueva, la cantidad de errores que se reportan en producción, la velocidad con la que se pueden corregir esos errores, la capacidad del sistema para soportar más usuarios o más transacciones sin degradarse.

Estas métricas deberían definirse antes de empezar la reconstrucción y medirse antes, durante y después del proceso. Antes, para tener una línea de base que justifique la inversión. Durante, para detectar desvíos a tiempo. Después, para confirmar que la reconstrucción cumplió su objetivo. Si pasaron seis meses desde que se terminó la reconstrucción y el tiempo para agregar una funcionalidad nueva no bajó, o los errores en producción no disminuyeron, la reconstrucción no logró lo que se proponía, sin importar lo bien que haya quedado el código.

Lo que se aprende cuando se empieza de nuevo

Reconstruir un sistema desde cero es una experiencia que ninguna empresa desea repetir. Pero las empresas que la atraviesan y aprenden de ella salen con algo que no tenían antes: la comprensión profunda de que el software no es un producto que se compra una vez y queda listo, sino un activo que requiere inversión continua en mantenimiento, orden y documentación.

Esa comprensión es la diferencia entre las empresas que reconstruyen una vez y nunca más, y las que entran en un ciclo de reconstruir cada tres o cuatro años porque nunca atacan las causas que las llevaron a la primera reconstrucción.

La pregunta no es si tu sistema actual va a necesitar una reconstrucción en algún momento. La pregunta es si cuando ese momento llegue, vas a tener claras las causas que te llevaron hasta ahí y el plan para no volver.