El coste real de la deuda técnica
La deuda que no aparece en el balance
La deuda técnica es el coste futuro de decisiones tecnológicas subóptimas tomadas en el pasado. Como la deuda financiera, tiene un principal (el trabajo que habría que hacer para corregirla) y un interés (el sobrecoste que genera cada día que no se corrige). A diferencia de la deuda financiera, no aparece en ningún balance, no tiene un acreedor que la reclame, y nadie la cuantifica hasta que es demasiado tarde.
El término fue acuñado por Ward Cunningham en 1992 como una metáfora para explicar a los directivos por qué el software se ralentiza con el tiempo. Tres décadas después, la metáfora sigue siendo imperfectamente entendida por la mayoría de las organizaciones.
Tipos de deuda técnica
No toda la deuda técnica es igual. Distinguir entre tipos es esencial para priorizarla:
Deuda deliberada: Decisiones conscientes de tomar atajos para cumplir un plazo. “Sabemos que esta arquitectura no escala, pero necesitamos lanzar este mes.” Si se documenta y se planifica su corrección, es deuda gestionada. Si no, es una bomba de relojería.
Deuda involuntaria: Decisiones que parecían correctas con la información disponible pero que resultaron subóptimas. Una tecnología que quedó obsoleta. Un patrón de diseño que no escaló como se esperaba (como discutimos en el contexto de la arquitectura hexagonal). Es inevitable y no implica error. Implica que la tecnología evoluciona.
Deuda por erosión: La más peligrosa. No viene de una decisión puntual sino de la acumulación de pequeñas degradaciones: un hotfix que nunca se hizo bien, una dependencia que no se actualizó, un test que se desactivó “temporalmente” hace dos años. Nadie la creó deliberadamente. Simplemente apareció.
Cómo se cuantifica
La deuda técnica se puede medir a través de indicadores objetivos:
- Tiempo de desarrollo de nuevas funcionalidades: Si una feature que debería tardar 2 semanas tarda 6, la diferencia es interés de deuda técnica. El equipo no es lento. El código es frágil.
- Tasa de regresión: Cada vez que un cambio rompe algo que funcionaba, la deuda técnica está actuando. Las regresiones son el interés compuesto de la deuda.
- Tiempo de onboarding: Si un desarrollador nuevo necesita meses para ser productivo, la complejidad accidental del sistema es alta.
- Ratio de trabajo planificado vs no planificado: Si el equipo dedica más del 30% de su capacidad a apagar incendios, la deuda técnica está generando interés activamente.
El efecto compuesto
Lo más peligroso de la deuda técnica es su naturaleza compuesta. No crece linealmente. Crece exponencialmente. Un sistema con poca deuda técnica absorbe cambios con facilidad. Un sistema con mucha deuda técnica convierte cada cambio en un riesgo.
El patrón típico es el siguiente: el equipo trabaja a buena velocidad durante los primeros 12-18 meses de un producto. Después, la velocidad empieza a caer. No dramáticamente al principio. Un 10% aquí, un 15% allá. Pero la caída se acelera. A los 3 años, el equipo puede estar dedicando el 60% de su tiempo a mantener lo que existe y solo el 40% a construir lo nuevo.
Las organizaciones que no gestionan su deuda técnica alcanzan un punto de inflexión donde el coste de modificar el sistema supera el coste de reconstruirlo. Ese es el momento más caro posible para actuar. Nuestro artículo sobre la modernización de sistemas legacy con el patrón strangler fig detalla cómo abordar esa situación de forma incremental.
Gestión estratégica, no eliminación
El objetivo no es eliminar la deuda técnica. Es gestionarla como una decisión estratégica. Algunas recomendaciones:
- Reservar un 20% de la capacidad del equipo para reducción de deuda técnica en cada sprint. No como un proyecto especial. Como parte del trabajo regular.
- Priorizar por impacto en velocidad, no por gravedad técnica. La deuda que más ralentiza al equipo hoy es la que debe corregirse primero.
- Documentar la deuda deliberada en el momento en que se crea. “Tomamos esta decisión porque X. Hay que corregirla antes de Y.”
- Medir la tendencia, no el absoluto. Lo importante no es cuánta deuda técnica tienes, sino si está creciendo o decreciendo.
- Hacer visible el coste al negocio. “Esta feature tarda 3 semanas en lugar de 1 porque el módulo X tiene deuda técnica sin resolver.” Cuando la dirección entiende el coste, apoya la inversión.
La deuda técnica como indicador de madurez
Las organizaciones maduras no son las que no tienen deuda técnica. Son las que la conocen, la miden y la gestionan deliberadamente. Es una señal de madurez ingeniería tan reveladora como el EBITDA lo es de madurez financiera.
Si tu equipo de tecnología no puede decirte cuánta deuda técnica tienen y cómo la están gestionando, ese es el primer problema a resolver. No porque sea una pregunta de ingeniería. Porque es una pregunta de negocio. Si necesitas una evaluación externa, nuestro equipo de consultoría tecnológica puede ayudarte a cuantificar y priorizar la deuda técnica de tu organización.
