Tu equipo entregaba una feature por semana y hoy tarda tres en lo mismo. La causa es la deuda técnica acumulada sprint a sprint, decisión a decisión, hasta que el costo de entrega pasó el punto en que alguien recuerda dónde empezó el problema.
La metáfora de Ward Cunningham
Ward Cunningham presentó la idea en 1992, en el relato del sistema WyCash: tomar la solución simple ahora y devolver el tiempo después, con intereses, en la refactorización. La deuda buena existe y rinde cuando el producto crece.
Casi toda la deuda que cargas es accidental. Nadie la decidió. Entra por una decisión apresurada, por un plazo cerrado sin seguimiento o por código que nadie tocó en tres años.
Tres tipos aparecen en el día a día:
- Deuda deliberada: "Lo hacemos así ahora, lo arreglamos después." El después casi nunca llega.
- Deuda inadvertida: el diseño correcto aparece recién con el código terminado, y el equipo corrige cuando el plazo lo permite.
- Deuda entrópica: el sistema funciona y nadie sabe por qué. El documento desapareció, el autor se fue, el equipo no toca el módulo.
La entrópica no figura en ningún backlog. Cobra cuando algo se rompe, y la cuenta llega con la investigación incluida. Michael Feathers describe ese módulo intocable en Working Effectively with Legacy Code (Prentice Hall, 2004).
Cómo la deuda cobra la velocidad
Tres disparadores hacen el trabajo. El ingeniero lee el sistema complejo antes de tocarlo y pierde días entendiendo el camino. Un cambio en A rompe B, porque los módulos hablan por efecto colateral. Nadie asume el cambio que puede tumbar producción, y la fila de decisión crece.
En la práctica, el equipo gasta tres semanas descubriendo dónde se conecta la feature y dos más asegurándose de que nada alrededor se rompió.
La curva es conocida: velocidad alta en los primeros meses, caída cada trimestre sin inversión en calidad. Después de dos o tres años, las features nuevas cargan tanta estabilización que el producto se detiene. Forsgren, Humble y Kim miden el efecto en Accelerate (2018): la entrega rápida acompaña automatización de deploy, tests confiables y trabajo de calidad planificado.
La deuda técnica es asunto de negocio
Un CTO que archiva la deuda como asunto de ingeniería pierde la conversación de presupuesto. El costo directo aparece en cinco lugares:
- Horas de ingeniería por feature entregada
- Bugs en producción y el costo de corregirlos
- Ingenieros que se van en vez de mantener un sistema malo
- Respuesta lenta a oportunidades de mercado
- Incidentes mayores a medida que el sistema se vuelve frágil
Convierte cada línea en horas y dinero, y la conversación con la dirección cambia de tono.
Tres formas de medir lo que debes
Mapa de puntos de dolor
Pregunta al equipo qué área da miedo tocar. Las respuestas marcan los módulos que ya cuestan caro. Un área que todo ingeniero evita es un área con deuda activa.
Tiempo de ciclo por área
Compara el tiempo medio de entrega en cada parte del sistema. La sección que tarda el triple es donde el equipo pierde días en cada pedido.
Bugs por módulo
Un módulo con bugs sobre la media suele tener acoplamiento alto y cobertura de teste baja. Sube la cobertura de ese módulo antes de refactorizar el resto.
Qué pagar primero
Deuda en un sistema legado que nadie usa queda estacionada. Deuda en la API que procesa el 80% de tu volumen pasa al frente, cueste lo que cueste.
Reserva entre 15% y 20% de la capacidad de ingeniería para refactorización, tests, documentación y actualización de dependencias. La reserva corre en cada sprint; un proyecto único no mueve la curva. Martin Fowler trata la práctica continua en Refactoring, 2ª edición (Addison-Wesley, 2018).
Los equipos que no reservan ese espacio llegan en 18 a 24 meses a un proyecto de reescritura, con alcance y plazo subestimados.
Diagnóstico antes de cualquier refactorización
Cuando la entrega bajó y la complejidad acumulada es la sospecha, pides un análisis honesto: cuánta deuda existe, dónde se concentra, cuánto cuesta cargarla y cuánto cuesta pagarla.
El análisis devuelve un número, deuda en dinero por área. Con el número sobre la mesa, decides qué pagas este trimestre y qué dejas para el siguiente.
