No toda deuda técnica debe pagarse. La pregunta no es si el código es mejorable, sino si esa mejora libera algo concreto.
Deuda no es lo mismo que código feo
Un módulo escrito de forma poco elegante que funciona, nadie toca y no falla no cuesta nada. Reescribirlo consume tiempo que no produce ningún beneficio observable.
La deuda que importa es la que tiene un costo actual medible: incidentes recurrentes, cambios que tardan desproporcionadamente, o un riesgo de seguridad activo.
Clasificación práctica
Cómo justificarlo ante quien aprueba el presupuesto
«El código está mal» no es un argumento presupuestable. «Este módulo generó nueve incidentes en el último trimestre, con un promedio de cuatro horas de atención cada uno» sí lo es.
Traducir la deuda a tiempo perdido, incidentes o riesgo cuantificado convierte una petición técnica en una decisión de negocio evaluable.
Evitar la reescritura total
La propuesta de reescribir el sistema completo es casi siempre una mala idea: pierde el conocimiento acumulado en años de correcciones, tarda más de lo estimado y durante la transición hay que mantener dos sistemas.
La alternativa que funciona es sustituir por partes, dejando el sistema antiguo operativo mientras cada pieza nueva demuestra equivalencia funcional.