Deuda Técnica
Nivel intermedio-avanzado — medir, priorizar y comunicar deuda técnica con datos, para negociar tiempo de remediación con argumentos de negocio.
El problema
"Necesitamos tiempo para refactoring" rara vez convence a un product manager. Sin datos concretos, la deuda técnica parece un capricho de ingeniería.
Situación típica: el equipo quiere dedicar un sprint a "limpiar código". Product dice: "no hay ROI visible, mejor hagamos features". Seis meses después: cada feature toma 3x más tiempo, hay 2 incidentes de producción al mes causados por código frágil, y 3 developers renuncian por frustración. Nunca se conectó esto con la deuda acumulada. // el coste existía, solo que nadie lo había medido
La metáfora de deuda (Ward Cunningham)
Principal = trabajo para arreglar el problema. Interés = coste extra en cada interacción con el código mientras no se paga.
Ejemplo: Principal = 2 semanas para refactorizar el módulo de auth. Interés por sprint = 3 días extra en cada feature que toca auth, 1 bug en producción al mes por código frágil, 2 horas de onboarding extra por nuevo desarrollador. Si no se paga, el interés se acumula.
4 tipos de deuda técnica
Prudente / Deliberada
"Hardcodeamos config, limpiamos post-launch" — atajo consciente con plan de pago
Prudente / Inadvertida
"Ahora que entendemos el dominio, el modelo es incorrecto" — aprendimos mejor forma después
Imprudente / Deliberada
"No tenemos tiempo para tests" — atajo sin plan de pago
Imprudente / Inadvertida
"Junior escribió esto sin code review" — no sabíamos que era malo
La deliberada y consciente ("prudente") no es un problema en sí — es una decisión de negocio informada. La imprudente es la que de verdad debería preocupar.
Métricas para medirla
| Métrica | Qué mide | Cómo obtenerla | Meta |
|---|---|---|---|
| Code Churn | Archivos que cambian repetidamente | Git history | <10% con >5 cambios/mes |
| Cyclomatic Complexity | Complejidad de funciones | SonarQube, ESLint | <10 por función |
| Code Coverage | % de código testeado | Test runner | >70% (no obsesionarse con 100%) |
| Bug Recurrence | Bugs en la misma área | Issue tracker | Tendencia descendente |
| Onboarding Time | Tiempo del nuevo dev en contribuir | Medición manual | <2 semanas para primer PR |
La propia tabla lo dice: >70% de cobertura, "no obsesionarse con 100%". Perseguir cobertura total desvía esfuerzo hacia tests de bajo valor (getters, configuración — exactamente lo que la Lección 5.3 marcaba como mala inversión) en vez de hacia la deuda que realmente genera interés alto. Una métrica que se persigue como objetivo en sí misma deja de medir lo que importaba.
Practica: registro de deuda técnica
Crea un registro de deuda técnica con al menos 3 items, cada uno clasificado en el cuadrante (tipo × intencionalidad), con métricas de impacto (interés que se está pagando) y una prioridad de remediación basada en esos datos, no en intuición.