La deuda técnica es el sobrecoste que pagas en cada cambio por atajos y defectos internos de un software. Se mide con métricas de código, como complejidad, duplicación, cobertura de tests y dependencias obsoletas, y con el tiempo que tarda un cambio en llegar a producción. Conviene pagarla cuando frena funcionalidades que generan ingresos. La gestionamos dentro de nuestro mantenimiento evolutivo de software a medida.
Imagina una empresa que pide a su proveedor un nuevo informe de ventas y recibe un presupuesto de tres semanas para algo que parecía de días. La diferencia suele estar en un código que nadie se atreve a tocar. Leer esas señales es tarea de un CTO externo para empresas de Madrid sin director técnico.
Al terminar podrás decidir qué parte de tu deuda pagar este trimestre y cuál dejar viva, y si antes necesitas una auditoría técnica del código que has heredado.
Qué es la deuda técnica
La deuda técnica es el coste futuro de mantener un software cuyo diseño interno dificulta modificarlo. Funciona como una deuda financiera: el principal es el trabajo de reordenar el código y los intereses son las horas extra que pagas en cada cambio mientras no lo haces.
Martin Fowler la clasificó en 2009 con dos ejes, deliberada o inadvertida y prudente o imprudente, en su cuadrante de la deuda técnica:
- Deliberada y prudente: el equipo sabe que toma un atajo y lo asume para lanzar antes.
- Deliberada e imprudente: se programa deprisa sabiendo que saldrá caro.
- Inadvertida e imprudente: el equipo desconoce las buenas prácticas de diseño y acumula deuda sin darse cuenta.
- Inadvertida y prudente: un buen equipo descubre a mitad de proyecto cuál habría sido el diseño correcto.
Cómo medir la deuda técnica de un software
La deuda técnica se mide combinando métricas de código, que dicen dónde está, con métricas de entrega, que dicen cuánto te cuesta.
- Complejidad ciclomática: número de caminos independientes dentro de una función. Cuanto más alta, más casos hay que probar antes de tocarla.
- Duplicación: bloques repetidos que obligan a corregir el mismo fallo en varios sitios.
- Cobertura de tests: porcentaje de código que ejecutan las pruebas automáticas. Con poca cobertura, cada cambio se valida en producción.
- Dependencias obsoletas: librerías con versiones mayores pendientes o sin soporte. `npm outdated` las lista en segundos.
- Change lead time (métrica de DORA): tiempo desde que un cambio entra en el repositorio hasta que llega a producción. Si crece trimestre a trimestre sin que crezca el equipo, la deuda está cobrando intereses.
SonarQube resume parte de esto en un ratio: el esfuerzo estimado para corregir los problemas de mantenibilidad dividido entre el coste de desarrollar el código, que por defecto calcula a 30 minutos por línea. Un ratio de hasta el 5 % da la calificación A de mantenibilidad, según la documentación de SonarQube sobre el ratio de deuda técnica.
Cuándo pagar la deuda técnica y cuándo convivir con ella
Conviene pagar la deuda técnica que vive en código que cambias a menudo; la que está en módulos estables puede esperar.
Págala ahora si:
- El módulo se toca en casi todos los sprints y cada cambio rompe algo.
- Usas dependencias sin parches de seguridad.
- Vas a construir una funcionalidad grande encima. Antes conviene aislar el dominio con arquitectura hexagonal.
- El sistema entero frena al negocio. Entonces toca modernizar la aplicación legacy por fases sin pararlo.
Convive con ella si:
- El código funciona y apenas cambia.
- Estás validando mercado y la prioridad es aprender rápido: es deuda deliberada y prudente.
- El módulo se va a sustituir en pocos meses.
- Te tienta partir el sistema en servicios: revisa antes la comparativa entre monolito modular y microservicios.
Cómo presupuestar la deuda técnica en el mantenimiento
La deuda técnica se presupuesta como una partida fija del mantenimiento, separada de las incidencias y de las funcionalidades nuevas.
Reserva un porcentaje de horas por sprint que decides tú y revisas cada trimestre con las métricas anteriores. Si sube el change lead time, aumenta la reserva; si baja, puedes liberar horas. Las partidas de mantenimiento correctivo y preventivo están desglosadas en nuestra guía sobre el coste real de mantener un software a medida. Cuando la deuda se concentra en integraciones antiguas, un middleware a medida para conectar el ERP con sistemas legacy permite pagarla sin tocar el núcleo.
CodeZone Pro Tip: este script recorre un repositorio Python con la librería radon y lista las funciones más complejas y los ficheros con peor índice de mantenibilidad.
"""Informe de deuda técnica para un repositorio Python. Requiere: pip install radon"""
import sys
from pathlib import Path
from radon.complexity import cc_rank, cc_visit
from radon.metrics import mi_visit
from radon.visitors import Function
UMBRAL = 10 # radon clasifica como C (riesgo moderado) a partir de 11
EXCLUIR = {".venv", "venv", "node_modules", "migrations"} # código que no mantienes tú
def analizar(repo: Path):
funciones, ficheros = [], []
for fichero in repo.rglob("*.py"):
if EXCLUIR & set(fichero.parts):
continue
codigo = fichero.read_text(encoding="utf-8", errors="ignore")
try:
bloques = cc_visit(codigo)
ficheros.append((mi_visit(codigo, multi=True), str(fichero)))
except SyntaxError:
continue # un fichero roto ya es un hallazgo; se revisa a mano
# Solo funciones y métodos: la complejidad de clase es un promedio y esconde picos
funciones += [(b.complexity, f"{fichero}:{b.lineno} {b.name}")
for b in bloques if isinstance(b, Function) and b.complexity > UMBRAL]
return sorted(funciones, reverse=True), sorted(ficheros)
if __name__ == "__main__":
funciones, ficheros = analizar(Path(sys.argv[1] if len(sys.argv) > 1 else "."))
print(f"Funciones con complejidad > {UMBRAL}: {len(funciones)}")
for cc, donde in funciones[:10]:
print(f" {cc_rank(cc)} {cc:>3} {donde}")
print("Ficheros con menor índice de mantenibilidad (0-100):")
for mi, nombre in ficheros[:5]:
print(f" {mi:5.1f} {nombre}")Ejecutado cada mes, el informe convierte una sensación ("este código está mal") en una lista de funciones y ficheros con nombre. Con ella pides un presupuesto de refactorización acotado y compruebas después si la complejidad bajó.
Lo Que Pagas Cuando la Deuda No Tiene Dueño
La deuda técnica sin medir se paga igual, repartida en presupuestos más largos y en cambios que rompen cosas. Medirla te permite elegir qué pagar y cuándo, en lugar de descubrirlo con una incidencia en producción.
Si quieres un primer informe de la deuda de tu aplicación y una propuesta para reducirla, pide una revisión de deuda técnica a nuestro equipo.
