«Hay que reescribirlo todo»: qué es la deuda técnica y cuándo es verdad

Llevas dos años pidiendo la misma funcionalidad pequeña: un filtro nuevo, un campo que se pueda editar, un informe que antes salía en un clic. Cada vez tarda más. El primer año era cosa de días. Este último cambio, que a simple vista parece igual de sencillo que los anteriores, ha costado tres semanas y ha traído dos efectos secundarios que nadie esperaba.

En algún momento de esa conversación aparece la frase: «el sistema no da más de sí, hay que reescribirlo desde cero». Suena a diagnóstico técnico, pero en realidad es una decisión de negocio de las caras: meses de equipo dedicados a repetir algo que ya funciona, con la promesa de que al final funcionará mejor. A veces esa promesa se cumple. Muchas veces no.

#Lo que de verdad significa «deuda técnica»

El nombre suena a jerga, pero la idea es la de cualquier deuda financiera: pediste prestado tiempo para ir más rápido ahora, y ese préstamo se paga con intereses más adelante. Nada de esto va de que el código sea «feo» ni de que a alguien no le guste cómo está escrito: va de coste, y se mide en dinero. Cada cambio nuevo sale más caro que el anterior, sobre lo mismo, para hacer algo parecido.

La señal que puedes medir sin abrir una sola línea de código es esta: lo que antes se resolvía en dos días ahora lleva dos semanas, y nadie en el equipo sabe explicarte por qué con precisión. Esa es la deuda técnica hecha factura. Se ve sin entender el sistema por dentro: basta con llevar la cuenta de cuánto tarda hoy lo que antes era rápido.

Y como cualquier deuda, no es automáticamente mala. Un negocio que pide un préstamo para abrir una segunda tienda antes de que lo haga la competencia está tomando una decisión razonable, siempre que sepa cuánto debe y cuándo lo va a devolver. El problema no es tener deuda técnica. Es no saber que la tienes, o no haber decidido tenerla a propósito.

#Por qué aparece: casi nunca es porque alguien lo hizo mal

Es tentador buscar un culpable: el proveedor anterior, el programador que se fue, la prisa del lanzamiento. La explicación real, en la inmensa mayoría de los casos, es más aburrida y menos satisfactoria: alguien tomó una decisión razonable con la información y el tiempo que tenía en ese momento, y esa decisión tuvo un coste que se paga después.

Piensa en una sala de conciertos que necesita vender entradas para un evento en tres semanas. El equipo técnico tiene dos opciones: montar el sistema de venta «bien», con todos los casos cubiertos, en dos meses; o montar una versión que cubre el 80% de los casos en dos semanas y deja el 20% restante —reembolsos parciales, entradas de acompañante, cambios de aforo de última hora— resueltos a mano por el equipo de taquilla mientras tanto. Elegir la segunda opción permite salir a vender entradas tres semanas antes, que en ese negocio puede ser la diferencia entre llenar la sala o no. Difícilmente se le puede llamar error.

El problema no nace ahí. Nace un año después, cuando ese 20% resuelto «a mano, de momento» sigue resolviéndose a mano, nadie ha vuelto a por él, y cada evento nuevo añade una excepción más sobre las anteriores.

#Cuándo reescribir sí tiene sentido

Hay tres situaciones en las que la reescritura completa deja de ser una opción cara y pasa a ser la más barata:

• La tecnología de base ya no recibe actualizaciones de seguridad. Si el sistema está construido sobre una pieza que su fabricante ha dejado de mantener, seguir sobre ella es acumular un riesgo que no se puede resolver con más parches, porque ya no hay parches. Llegado ese punto ya no se trata de seguir pagando la deuda, sino de que el banco ha cerrado y ya no acepta pagos.
• Ya no queda nadie en el mercado que sepa mantenerlo. Un sistema construido con una herramienta que dejó de usarse hace años se puede mantener mientras esté la persona que lo conoce. El día que esa persona se va, cada cambio exige primero encontrar a alguien dispuesto a aprender algo que nadie más enseña. Eso ya no se parece a una deuda técnica corriente: el sistema ha dejado de tener mercado de mantenimiento.
• El negocio ha cambiado tanto que el sistema resuelve un problema que ya no tienes. Un restaurante que empezó con un único local y ahora gestiona ocho no necesita «arreglar» el sistema pensado para uno solo. Necesita otro, porque el problema que resolvía el primero —gestionar una cocina y una caja— ya no es el problema que tiene la empresa hoy.

Fuera de estos tres casos, «hay que reescribirlo todo» suele ser una frase que promete más de lo que puede cumplir.

#Cuándo es una mala idea

Hay tres señales que, cuando aparecen, deberían hacer sonar una alarma antes de aprobar el presupuesto de una reescritura completa:

• Quien lo propone acaba de llegar. Es la reacción más humana del mundo: a nadie le gusta heredar un sistema que no entiende del todo, y siempre es más cómodo construir uno nuevo que aprender por qué el viejo hace las cosas de una manera concreta. El riesgo es confundir «no lo entiendo» con «está mal hecho».
• Nadie tiene claro qué hace el sistema hoy. Si no hay una lista fiable de todos los casos que el sistema ya resuelve —incluidos los raros, los que ocurren dos veces al año, los que un cliente pidió como excepción hace tres temporadas—, una reescritura no parte de cero: parte de menos que cero, porque va a olvidar cosas que el sistema actual ya sabe hacer sin que nadie se acuerde de por qué.
• La razón real es que al equipo le apetece trabajar con otra herramienta. Es legítimo que un equipo técnico quiera actualizar sus herramientas de trabajo. No es legítimo presentarlo como una necesidad del negocio cuando en realidad es una preferencia del equipo. Ambas cosas pueden ser ciertas a la vez; conviene que quien decide sepa cuál está pesando más.

El coste real de una reescritura completa casi nunca es solo el presupuesto que se pide. Es el tiempo, normalmente contado en meses, durante el cual el sistema nuevo no puede recibir peticiones nuevas porque el equipo está ocupado reconstruyendo lo que ya existía. Ese es el precio que se paga en silencio, y el que con más frecuencia se subestima al aprobar el proyecto.

#La tercera vía que casi nadie propone

Entre «seguir como estamos» y «tirarlo todo y empezar de cero» hay una opción intermedia que rara vez llega a la mesa de decisión, porque es menos vistosa: sustituir el sistema por partes, dejando el antiguo funcionando mientras se reemplazan piezas una a una.

La idea es sencilla de explicar con un ejemplo. Si una sala de conciertos quiere renovar su sistema de venta de entradas, no hace falta apagar el actual el día que empieza el proyecto nuevo. Se puede construir primero, aparte, solo el módulo de reembolsos —que es el que más falla— y ponerlo a convivir con el resto del sistema antiguo. Cuando ese módulo funciona bien, se sustituye el siguiente. El sistema nunca deja de vender entradas mientras se renueva, y si algo del plan resulta no funcionar, el coste de dar marcha atrás es el de esa pieza, no el de todo el proyecto.

Esta vía tarda más en llegar al resultado final que una reescritura completa bien planificada. A cambio, reduce drásticamente el riesgo de que, a mitad de camino, se descubra que el plan tenía un fallo grave y ya no haya vuelta atrás posible sin perder meses de trabajo.

#Las tres preguntas antes de aprobar una reescritura

Si la próxima vez que alguien te proponga «reescribirlo todo» solo tienes tiempo para hacer tres preguntas, que sean estas:

1. ¿Qué pasa si no lo hacemos? No como frase retórica, sino como respuesta concreta: qué se rompe, cuándo, y con qué gravedad. Si la respuesta es vaga, la urgencia probablemente también lo es.
2. ¿Cuánto tiempo vamos a estar sin poder añadir nada nuevo al sistema actual? Esa cifra —normalmente medida en meses— es el coste real del proyecto, más allá del presupuesto que aparece en la propuesta.
3. ¿Qué parte se puede hacer primero, para comprobar que la idea funciona antes de comprometer el resto? Si nadie puede señalar una primera pieza pequeña y verificable, es una señal de que el plan no está tan claro como parece en la reunión.

Ninguna de las tres exige saber programar. Exigen algo más difícil de fingir: que quien propone la reescritura se haya hecho esas preguntas antes que tú.