Deuda técnica

La deuda técnica es el costo futuro que generan los atajos técnicos o el mantenimiento postergado, y que vuelve los cambios más lentos y riesgosos hasta que se paga.

Ward Cunningham introdujo la metáfora de la deuda para explicar un compromiso a personas no técnicas. Entregar hoy una solución rápida es como pedir dinero prestado. Obtienes algo antes y después pagas intereses: cada cambio posterior en esa zona toma más tiempo del que tomaría con una solución limpia. Pagar el capital es volver y hacer el trabajo bien.

La deuda tiene varios orígenes:

• Atajos deliberados para cumplir una fecha.
• Decisiones que eran razonables en su momento y hoy están desactualizadas.
• Dependencias y frameworks que nunca se actualizaron.
• Pruebas y documentación que faltan.

Ejemplo

Un equipo se queda en AngularJS después del fin de soporte porque el roadmap está lleno. Ese mes no se rompe nada. Los intereses aparecen después. Una librería que necesitan solo soporta frameworks modernos. Una auditoría de seguridad marca la dependencia sin soporte. Los candidatos rechazan ofertas por el stack. Cada año la migración es más grande, porque las funcionalidades nuevas se siguen escribiendo en el framework viejo.

Confusión frecuente

Aquí se mezclan dos ideas. Primero, deuda y mal código son cosas distintas. Un atajo cuidadoso, tomado con un plan para corregirlo, es deuda. El trabajo descuidado y sin plan es simplemente mala calidad. Segundo, endeudarse puede ser una buena decisión, como con un préstamo, cuando el equipo conoce los intereses y los va pagando.

El problema empieza cuando la deuda es invisible. Hazla concreta: lista los ítems, estima cuánto cuesta cada uno en entregas más lentas o en riesgo, y pon los más grandes en el roadmap junto a las funcionalidades. La guía de opciones ante el fin de soporte de AngularJS muestra cómo se aplica esto a un framework sin soporte.

Términos relacionados

• Código legacy (código heredado)
• Fin de soporte (EOL, end of life)
• Reescritura big bang