Deuda técnica: cómo decidir qué arreglar y qué dejar
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
Deuda que sangra: produce incidentes en producción de forma repetida. Se paga primero, siempre.Deuda que frena: cada cambio en esa zona cuesta el triple de lo razonable. Se paga cuando hay trabajo previsto en esa zona.Deuda de riesgo: dependencias sin soporte, versiones fuera de mantenimiento, ausencia de pruebas en lógica crítica. Se paga de forma planificada antes de que se convierta en urgente.Deuda cosmética: inconsistencias de estilo, nombres mejorables. Se paga solo si se toca la zona por otro motivo.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.
¿Su sistema es cada vez más caro de mantener?
Escríbanos con el contexto de su organización. Respondemos con criterio técnico, no con un formulario de ventas.
Contactar