Un sistema legacy es código sin dueño

Qué convierte un sistema en legacy

Un sistema es legacy cuando ya no hay nadie que responda de él. La edad del código apenas cuenta: hay sistemas con muchos años encima que se tocan sin sobresaltos, y aplicaciones del año pasado que ya da miedo mirar.

La diferencia está en si queda alguien que sepa contestar, delante de un cambio, por qué el sistema está hecho así y qué se rompe al tocarlo. Y si hay manera de enterarse de que se ha roto algo sin esperar a que llame un cliente. Cuando esas respuestas viven solo en la memoria de una persona, el sistema depende de que esa persona siga disponible.

El síntoma que buscamos es que haya partes que el equipo evita tocar y que esa decisión no la discuta nadie.

Las cinco situaciones, contadas desde dentro

Hay una parte que nadie toca desde hace meses. Suele ser la que calcula algo con dinero. El equipo ha aprendido a trabajar alrededor: se añaden funciones nuevas por fuera, se copian datos a otra tabla, se hace un ajuste manual al cierre de mes. Cada rodeo añade un sitio más donde el mismo número puede salir distinto.

Todo depende de una persona o de un proveedor. El proveedor contesta, hace el cambio y factura. El problema aparece el día que quieres pedir presupuesto a otro: nadie más tiene acceso al servidor, o el repositorio está en la cuenta de la agencia. Ahí el precio deja de negociarse.

Alguien de fuera va a mirar por dentro. Un cliente grande manda su cuestionario de seguridad, o entra un inversor, o toca una auditoría. Piden cosas que existen o no existen, sin término medio: quién tiene acceso a qué, qué se guarda de los usuarios, qué pasa si se pierde la base de datos. Preparar eso con dos semanas de aviso sale mal.

Hay muchos más clientes que cuando se hizo. Ningún proceso se volvió manual por decisión: algo empezó a fallar de vez en cuando y se montó una hoja de cálculo para repasarlo. Con el tiempo esa hoja es parte del sistema y no está documentada en ninguna parte.

Quien lo escribió ya no está. El código funciona, hace lo que tiene que hacer, y nadie sabe por qué toma buena parte de sus decisiones. Cada cambio empieza por averiguar por qué está así.

Lo primero: acceso, lectura y reproducir el fallo

El trabajo empieza consiguiendo acceso real, no una demo. Repositorio, base de datos de un entorno que no sea el de producción, registros de errores, y la lista de servicios externos con los que habla el sistema. Cuando conseguir eso cuesta más de una semana, ya sabemos algo del proyecto.

Después se lee, y se lee por donde el negocio duele. Si el problema es la facturación, se sigue el camino de una factura desde que alguien pulsa el botón hasta que el cliente la recibe, anotando cada sitio donde el sistema toma una decisión que nadie ha documentado.

Lo tercero es reproducir el fallo. Mientras un error solo pasa en producción y de vez en cuando, no se puede arreglar con criterio. Buena parte de las primeras semanas se va en conseguir que ocurra a voluntad en una máquina que no es la del cliente. Es también cuando aparecen los errores que nadie había reportado, porque el equipo había dejado de contarlos.

Operamos BeeL, nuestra plataforma de facturación, así que los fallos raros de un sistema en producción los recibimos nosotros.

Por qué reescribir de cero casi nunca es la respuesta

El sistema que quieres tirar contiene años de reglas de negocio que nadie escribió en ningún sitio. La única copia de esas reglas es el código que quieres borrar.

Mientras se escribe el sistema nuevo, el viejo tiene que seguir funcionando y recibiendo cambios. Durante meses hay dos sistemas que mantener con el mismo equipo, y el viejo gana siempre, porque es el que tiene clientes dentro.

A eso se suman las reglas raras, las que se pusieron porque un cliente concreto lo pidió hace años. Van apareciendo de una en una, cuando alguien se queja de que el sistema nuevo ha dejado de hacer algo. Y una reescritura no entrega nada hasta el final, así que a mitad de camino alguien se plantea cancelarla.

La alternativa que usamos: se elige la parte que más duele, se rodea de comprobaciones que se ejecutan solas, se sustituye por dentro y se entrega. El sistema sigue en producción todo el tiempo. Si el presupuesto se acaba a mitad, lo entregado ya está funcionando.

Reescribir de cero tiene sentido cuando lo que el negocio necesita ahora se parece poco a lo que el sistema hace. Si un ERP montado para gestionar almacén tiene que pasar a vender por internet, el problema deja de ser el código y la conversación es de producto.

Cómo se recupera un dueño

Un sistema deja de ser legacy cuando alguien que no lo ha escrito puede cambiarlo. Esa es la prueba, y se puede hacer en directo.

Nuestra cuarta condición de entrega dice justo eso y va en el contrato. Antes de cerrar, una persona que no ha visto nunca el proyecto hace un cambio real que elige el cliente, con el repositorio y nada más. Tiene que poder encontrar la decisión que explica por qué está así, hacer el cambio sin preguntarle a nadie y saber por las pruebas si ha roto algo. Si no sale, falta documentación y se escribe antes de facturar el último hito.

Eso cambia qué se entiende por documentación. Sirve lo que permite a un extraño hacer un cambio concreto: las decisiones escritas junto al código, con su fecha y lo que se descartó, y las reglas de negocio convertidas en comprobaciones que se ejecutan en cada cambio y se leen sin ser programador.

Al equipo del cliente le sirve el mismo día que se va el proveedor, y le sirve con la herramienta que use cada uno para programar. Lo que un modelo necesita para tocar un sistema sin romperlo es lo mismo que necesita una persona nueva: encontrar el porqué y tener algo que le avise del error.

Por dónde se empieza

Si al leer las cinco situaciones has reconocido tu sistema en dos o más, lo que falta antes de decidir nada es un número: cuánto cuesta arreglarlo, qué se rompe primero, y qué pasa si no se hace este año.

Para eso existe el diagnóstico. Si sale pequeño, lo decimos y no hay proyecto.