Cómo medir la deuda técnica

Métricas para cuantificar, gestionar y comunicar su impacto.

Resumen

La deuda técnica es uno de esos conceptos que casi todo equipo de ingeniería reconoce de forma intuitiva, pero que muy pocos consiguen medir con disciplina. La consecuencia es conocida: las conversaciones sobre calidad quedan reducidas a frases vagas ("el código está enredado", "esto hay que refactorizar") que rara vez convencen a quien controla el presupuesto. Este artículo desarrolla el marco de cinco capas que resume la infografía y propone una idea central: ninguna métrica aislada cuenta toda la historia. Medir la deuda técnica con utilidad exige combinar indicadores de código, de proceso, financieros y humanos, y traducir cada uno al lenguaje de la audiencia que debe tomar la decisión.

1. Qué es la deuda técnica y por qué medirla

El término lo acuñó Ward Cunningham en 1992 como metáfora financiera: tomar un atajo de diseño es como pedir un préstamo. El atajo permite entregar más rápido (se recibe el "principal"), pero genera un coste recurrente —los "intereses"— que se paga cada vez que alguien trabaja sobre ese código deficiente. Mientras la deuda no se salda, los intereses se acumulan y encarecen cada cambio futuro.

La metáfora explica por qué medirla importa. Una deuda con intereses bajos puede convivir indefinidamente con el sistema sin causar daño; otra, sobre un módulo que se modifica todas las semanas, drena capacidad de entrega de forma silenciosa. El objetivo de la medición no es perseguir un código perfecto, sino distinguir la deuda tolerable de la peligrosa y priorizar la remediación donde el retorno es mayor.

El reto es que la deuda técnica es multidimensional: tiene una cara técnica (complejidad, duplicación), una de proceso (lentitud de entrega), una financiera (coste de oportunidad) y una humana (fricción y dependencia del conocimiento). No existe un único número que capture todas esas dimensiones, motivo por el cual las organizaciones maduras recurren a una combinación de métricas. Las cinco familias que siguen forman ese tablero de control.

2. Cuantificación primaria: el Technical Debt Ratio (TDR)

Si se necesita un único indicador de cabecera, el más recomendado por su simplicidad es el Technical Debt Ratio (TDR), popularizado por el método SQALE y por herramientas como SonarQube. Se define como:

TDR = (Costo de Remediación / Costo de Desarrollo) × 100

Sus dos componentes son:

• Costo de Remediación (principal): el esfuerzo estimado para corregir todos los problemas identificados —refactorizar código, actualizar dependencias, eliminar duplicación, etc.—. Las herramientas de análisis estático lo calculan asignando un tiempo de reparación a cada incidencia detectada.
• Costo de Desarrollo: el esfuerzo estimado para construir el sistema desde cero, normalmente derivado de las líneas de código mediante un factor de productividad, o bien el esfuerzo total ya invertido.

El TDR expresa, en porcentaje, qué fracción del valor del sistema tendría que reinvertirse solo para dejarlo sano. Un valor del 8 % significa que reparar la deuda costaría aproximadamente el 8 % de lo que costó construir el sistema. Como rangos de referencia:

Nota: la versión original de la infografía mostraba la última banda como "> 30 %", lo que dejaba sin clasificar el tramo del 10 % al 30 %. Aquí se presenta como "> 10 %" para que las tres bandas sean contiguas, en línea con los umbrales por defecto de las herramientas de análisis estático.

El TDR tiene una virtud —es un número único, comparable entre proyectos y fácil de comunicar— y una limitación que conviene no olvidar: trata toda la deuda por igual. No distingue entre una incidencia en un módulo muerto y otra en el corazón transaccional del sistema. Por eso el TDR sirve como termómetro general, pero debe complementarse con las métricas de las secciones siguientes.

3. Procesos y rendimiento: DORA, SPACE y el modelo TDIM

Las métricas anteriores miden el estado del código. Las de proceso miden algo más persuasivo para la dirección: cómo la deuda degrada el rendimiento real de la entrega. Aquí el marco de referencia son las métricas DORA y los marcos SPACE de productividad de ingeniería.

Esta relación dejó de ser anecdótica. Un estudio revisado por pares publicado en 2026 (American Impact Review) propuso el Technical Debt Impact Model (TDIM) a partir del análisis de 89 proyectos empresariales y de una encuesta a más de 400 líderes de ingeniería. El estudio establece correlaciones estadísticamente significativas entre la densidad de deuda técnica y la degradación de tres métricas DORA: frecuencia de despliegue, tiempo de entrega de cambios y tasa de fallos de cambio. Más concretamente, encontró que un aumento de una desviación estándar en la relación deuda-código se asocia con una caída cercana al 23 % en la velocidad de entrega y un incremento del 31 % en la densidad de defectos.

Las cuatro señales prácticas que conviene seguir son:

• Frecuencia de despliegue. Los niveles altos de deuda se asocian estadísticamente con una menor frecuencia de despliegue: el equipo lanza con menos confianza y menos a menudo.
• Tiempo de entrega de cambios. La deuda alarga el tiempo que transcurre desde que se confirma el código (commit) hasta que llega a producción. La evidencia apunta a que el código saludable se desarrolla en torno al doble de rápido que el no saludable.
• Tasa de fallos de cambio. Los proyectos con ratios de deuda elevados experimentan tasas de fallo en despliegue significativamente más altas.
• Seguimiento de la velocidad (velocity). Una disminución sostenida de la velocidad de los sprints, más allá de la variación normal, suele indicar que el equipo está dedicando capacidad a luchar contra la deuda en lugar de entregar nuevas funcionalidades.

El valor de estas métricas es doble: son objetivas (salen de la telemetría de las herramientas de CI/CD) y hablan el idioma del negocio, porque "entregamos la mitad de rápido" se entiende sin necesidad de explicar qué es la complejidad ciclomática.

4. Análisis estático y métricas de código

Para localizar dónde vive la deuda hacen falta métricas granulares a nivel de código, que producen herramientas automatizadas como SonarQube, Designite o Arcan. Las cuatro más informativas son:

• Complejidad ciclomática. Mide el número de caminos de ejecución independientes a través de una función o módulo. Una mayor complejidad se correlaciona directamente con mayor dificultad de mantenimiento, mayor esfuerzo de prueba y más fallos. Es uno de los predictores más fiables de los puntos del código que serán costosos de tocar.
• Duplicación de código. Identifica fragmentos redundantes. La duplicación es perniciosa porque crea múltiples puntos de falla —un mismo defecto debe corregirse en varios lugares— y multiplica el esfuerzo de mantenimiento cada vez que cambia una regla de negocio.
• Code churn (rotación de código). Mide el porcentaje de código que un desarrollador modifica o reescribe poco tiempo después de haberlo escrito. Una rotación elevada suele delatar implementaciones iniciales deficientes, requisitos poco claros o áreas inestables del producto. Es una señal temprana valiosa, porque aparece antes de que la deuda se consolide.
• Cobertura de pruebas. Un porcentaje bajo o decreciente de cobertura de pruebas automáticas constituye una "deuda de pruebas": cada cambio se vuelve más arriesgado y aumenta la probabilidad de regresiones. La cobertura no garantiza calidad por sí sola, pero su tendencia a la baja es un indicador de alerta confiable.

Conviene leer estas métricas como un mapa de calor, no como una nota de examen. Su utilidad está en priorizar: una función con alta complejidad, mucha rotación y baja cobertura, situada en una ruta crítica, es exactamente el tipo de deuda que merece atención inmediata.

5. Impacto financiero y económico

Para convencer a stakeholders no técnicos, la deuda debe dejar de medirse en horas o en complejidad y traducirse en dinero y valor de negocio. Estas cuatro métricas hacen esa traducción.

• Costo anual de la deuda. Es la forma más directa de poner cifra al "interés". Se estima multiplicando las horas semanales que el equipo pierde por culpa de la deuda por el costo por hora del equipo, y por 52 semanas. Si un equipo dedica el 20 % de cada sprint a sortear deuda, ese porcentaje convertido a coste anual suele ser una cifra que capta la atención de cualquier dirección financiera.
• Costo de la demora (Cost of Delay). Cuantifica el impacto en los ingresos derivado de entregar funcionalidades más tarde de lo posible, precisamente por la fricción que causa la deuda. Es la métrica que conecta la calidad interna con el resultado comercial.
• Probabilidad de interés (Interest Probability). No toda la deuda "cobra intereses". Esta métrica estima la probabilidad de que un elemento concreto de deuda llegue de verdad a costar tiempo al equipo en el futuro, en función de la frecuencia con la que se modifica ese código. Permite ignorar con tranquilidad la deuda en zonas estables y concentrar el esfuerzo donde el código cambia a menudo.
• Retorno de inversión (ROI) de la remediación. Compara el beneficio de corregir la deuda frente al costo de implementarlo. Aquí la evidencia reciente es notablemente favorable: el mismo estudio de 2026 que formuló el TDIM concluyó que la remediación sistemática de deuda arquitectónica produce un ROI mediano del 437 % a 24 meses, con un punto de equilibrio de apenas 6,2 meses; para la deuda de diseño, el ROI mediano fue del 287 %, con equilibrio a 4,7 meses. Estas cifras —coherentes con la observación de la industria de que cada unidad de deuda no atendida hoy cuesta varias veces más mañana— convierten la remediación, cuando se prioriza bien, en una de las inversiones de ingeniería con mejor retorno demostrable.

6. Métricas cualitativas y humanas

La última capa captura algo que los números de código no ven: la fricción que la deuda provoca en las personas. Son señales más blandas, pero a menudo las primeras en aparecer.

• Fricción en Pull Requests (PR friction). Monitorear revisiones que se alargan o que acumulan demasiados ciclos de ida y vuelta en módulos concretos ayuda a identificar los "puntos calientes" de deuda. Si un área del código siempre genera discusiones largas, esa área está pidiendo atención.
• Tiempo de onboarding. Cuando cada vez lleva más tiempo que una persona nueva se vuelva productiva, suele indicar una alta "deuda de documentación" o sistemas excesivamente complejos. Es un indicador retardado pero muy revelador del estado real de mantenibilidad.
• Impuesto de silos de conocimiento (Knowledge Silo Tax). Es el riesgo operacional en el que se incurre cuando una sola persona entiende una parte específica y poco documentada del sistema. Aumenta la probabilidad de interrupciones y crea una dependencia crítica: si esa persona se ausenta, el conocimiento se va con ella. Métricas como el bus factor ayudan a cuantificarlo.

7. Cómo combinar las métricas

El error más común al medir deuda técnica es buscar "la métrica" definitiva. Como muestra el conjunto anterior, cada capa responde a una pregunta distinta: el TDR dice cuánta deuda hay; las métricas de proceso, cuánto duele; las de código, dónde está; las financieras, cuánto cuesta y cuánto rinde repararla; y las humanas, a quién y cómo afecta.

La práctica recomendada es construir un pequeño tablero que recoja al menos un indicador de cada familia y adaptar la presentación a la audiencia: a un equipo de ingeniería le hablan la complejidad ciclomática y la cobertura; a un comité de dirección, el costo anual de la deuda y el ROI de la remediación. La misma realidad técnica, traducida a dos idiomas distintos.

Tres recomendaciones prácticas cierran el marco. Primero, medir tendencias antes que valores absolutos: un TDR del 9 % en descenso es una situación muy distinta de un 7 % en ascenso. Segundo, priorizar por probabilidad de interés: refactorizar código que nadie toca es esfuerzo malgastado. Tercero, presentar siempre la deuda con su contrapartida económica: "este módulo nos cuesta X al año y arreglarlo se paga solo en seis meses" mueve presupuestos que "el código está enredado" nunca moverá.

8. Conclusión

Medir la deuda técnica no consiste en encontrar un número mágico, sino en componer una imagen completa a partir de varias perspectivas. Combinar métricas técnicas, de proceso, financieras y humanas proporciona esa visión integral y permite tomar decisiones informadas: qué deuda tolerar, cuál remediar primero y cómo justificar la inversión ante quien la aprueba. La deuda técnica bien medida deja de ser una queja recurrente del equipo de ingeniería para convertirse en lo que realmente es: una variable de negocio gestionable.