En pocas palabras
Práctica para identificar los atajos y el deterioro del código o la arquitectura, cuantificar su «interés» y decidir conscientemente cuándo pagar, convivir o reemplazar.
Qué problema resuelve
Deuda invisible para negocio que se discute como opinión técnica, nunca entra en la planificación y frena cada vez más la entrega.
Cuándo utilizarlo
Planificación trimestral, conversaciones con producto o cuando la velocidad cae. Ejemplo: justificar dedicar un sprint a desacoplar el módulo de pagos.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
El cuadrante de Fowler
| Deliberada | Inadvertida | |
|---|---|---|
| Prudente | «Lanzamos ahora y refactorizamos tras la campaña» | «Ahora sabemos cómo deberíamos haberlo diseñado» |
| Imprudente | «No hay tiempo para pruebas» | «¿Qué es una capa?» |
Solo la deliberada y prudente es una decisión de negocio legítima. La inadvertida y prudente es inevitable: aprender genera deuda. Las imprudentes son problemas de capacidad o de cultura.
Hacerla visible: el registro de deuda
| Campo | Ejemplo |
|---|---|
| Descripción | El cálculo de intereses está duplicado en tres servicios |
| Impacto | Cada cambio regulatorio exige tocar tres sitios; dos defectos en 2026 |
| Interés | ~3 días extra por cambio; 6 cambios previstos al año |
| Coste de pago | 8 días: extraer a una librería o servicio con pruebas |
| Riesgo | Alto: errores en importes a clientes |
| Decisión | Pagar en el Q4, antes del cambio de tasas de enero |
Con interés y coste estimados, la conversación con producto pasa de «el código está mal» a «invertir 8 días ahorra 18 al año y reduce un riesgo regulatorio».
Dónde está la deuda que duele: hotspots
Cruza dos señales del control de versiones:
- Frecuencia de cambio de cada archivo (
git log). - Complejidad del archivo (ciclomática, tamaño, anidamiento).
git log --since=12.months --name-only --format= | sort | uniq -c | sort -rn | head -20Los archivos que cambian mucho y son complejos concentran el interés. Código complejo que nadie toca rara vez es prioritario. Herramientas como CodeScene, SonarQube o Mapping code smells to refactoring techniques ayudan a priorizar y a elegir la refactorización.
Estrategias de pago
| Estrategia | Cuándo |
|---|---|
| Regla del boy scout | Mejoras pequeñas al tocar el código; continuo |
| Capacidad reservada (10–20 %) | Deuda mediana, sin necesidad de negociar cada vez |
| Iniciativa dedicada | Deuda estructural con caso de negocio explícito |
| Reemplazo (strangler fig) | Cuando refactorizar cuesta más que sustituir |
Antipatrones frecuentes
- «Sprint de deuda» anual: se acumula durante meses y nunca alcanza.
- Pagar deuda en código estable mientras el hotspot sigue creciendo.
- Usar «deuda técnica» para cualquier cosa que no gusta a ingeniería, lo que erosiona la credibilidad.
Cuantificar el interés
| Fuente de evidencia | Ejemplo de dato |
|---|---|
| Tiempo de ciclo por área del código | Cambios en pagos/ tardan 3× la mediana del repositorio |
| Defectos por módulo | El 40 % de los incidentes del año tocan el módulo de intereses |
| Trabajo no planificado | 30 % del sprint dedicado a soporte y correcciones |
| Encuesta al equipo | «El módulo X es la principal fuente de frustración» |
| Onboarding | Las personas nuevas tardan semanas en tocar el módulo |
No hace falta precisión contable: un orden de magnitud bien argumentado basta para priorizar frente a otras iniciativas.
Comunicarla a negocio
| En lugar de… | Decir… |
|---|---|
| «El código de pagos está muy acoplado» | «Cada cambio regulatorio en pagos cuesta 3 semanas; podría costar 1» |
| «Hay que actualizar el framework» | «La versión actual deja de recibir parches de seguridad en marzo» |
| «Necesitamos refactorizar» | «Invertir 2 sprints reduce a la mitad los incidentes de cobranza» |
Vincula cada elemento de deuda a un objetivo de negocio: velocidad, riesgo, coste o cumplimiento.
Revisión trimestral
- Actualizar el registro con los hotspots y los datos de los últimos tres meses.
- Ordenar por
interés × riesgo / coste de pago. - Acordar con producto los elementos que entran en el trimestre y la capacidad reservada.
- Revisar la deuda pagada: ¿bajó el interés como se esperaba?
- Registrar las deudas deliberadas nuevas con su fecha de pago.
Indicadores para la gerencia
- Porcentaje de capacidad dedicado a trabajo no planificado (tendencia).
- Deployment rework rate y change fail rate de las métricas DORA.
- Edad de las versiones de frameworks y dependencias principales respecto a la última soportada.
- Número de elementos del registro con interés alto sin plan.
Si el trabajo no planificado crece de forma sostenida, la deuda ya está cobrando intereses aunque nadie la haya registrado.
Criterios de implementación
Mantén el registro junto al backlog de producto, no en un documento aparte. Revisa los diez elementos de mayor interés en cada planificación trimestral. Protege la deuda deliberada con un ADR que diga cuándo se pagará, y evita la nueva con fitness functions.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.