El coste real de la deuda tecnica
La deuda que no aparece en el balance
La deuda tecnica es el coste futuro de decisiones tecnologicas suboptimas tomadas en el pasado. Como la deuda financiera, tiene un principal (el trabajo que habria que hacer para corregirla) y un interes (el sobrecoste que genera cada dia que no se corrige). A diferencia de la deuda financiera, no aparece en ningun balance, no tiene un acreedor que la reclame, y nadie la cuantifica hasta que es demasiado tarde.
El termino fue acuñado por Ward Cunningham en 1992 como una metafora para explicar a los directivos por que el software se ralentiza con el tiempo. Tres decadas despues, la metafora sigue siendo imperfectamente entendida por la mayoria de las organizaciones.
Tipos de deuda tecnica
No toda la deuda tecnica 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 correccion, es deuda gestionada. Si no, es una bomba de relojeria.
Deuda involuntaria: Decisiones que parecian correctas con la informacion disponible pero que resultaron suboptimas. Una tecnologia que quedo obsoleta. Un patron de diseño que no escalo como se esperaba. Es inevitable y no implica error. Implica que la tecnologia evoluciona.
Deuda por erosion: La mas peligrosa. No viene de una decision puntual sino de la acumulacion de pequeñas degradaciones: un hotfix que nunca se hizo bien, una dependencia que no se actualizo, un test que se desactivo “temporalmente” hace dos anos. Nadie la creo deliberadamente. Simplemente aparecio.
Como se cuantifica
La deuda tecnica se puede medir a traves de indicadores objetivos:
- Tiempo de desarrollo de nuevas funcionalidades: Si una feature que deberia tardar 2 semanas tarda 6, la diferencia es interes de deuda tecnica. El equipo no es lento. El codigo es fragil.
- Tasa de regresion: Cada vez que un cambio rompe algo que funcionaba, la deuda tecnica esta actuando. Las regresiones son el interes 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 mas del 30% de su capacidad a apagar incendios, la deuda tecnica esta generando interes activamente.
El efecto compuesto
Lo mas peligroso de la deuda tecnica es su naturaleza compuesta. No crece linealmente. Crece exponencialmente. Un sistema con poca deuda tecnica absorbe cambios con facilidad. Un sistema con mucha deuda tecnica convierte cada cambio en un riesgo.
El patron tipico es el siguiente: el equipo trabaja a buena velocidad durante los primeros 12-18 meses de un producto. Despues, la velocidad empieza a caer. No dramaticamente al principio. Un 10% aqui, un 15% alla. Pero la caida se acelera. A los 3 anos, 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 tecnica alcanzan un punto de inflexion donde el coste de modificar el sistema supera el coste de reconstruirlo. Ese es el momento mas caro posible para actuar.
Gestion estrategica, no eliminacion
El objetivo no es eliminar la deuda tecnica. Es gestionarla como una decision estrategica. Algunas recomendaciones:
- Reservar un 20% de la capacidad del equipo para reduccion de deuda tecnica en cada sprint. No como un proyecto especial. Como parte del trabajo regular.
- Priorizar por impacto en velocidad, no por gravedad tecnica. La deuda que mas ralentiza al equipo hoy es la que debe corregirse primero.
- Documentar la deuda deliberada en el momento en que se crea. “Tomamos esta decision porque X. Hay que corregirla antes de Y.”
- Medir la tendencia, no el absoluto. Lo importante no es cuanta deuda tecnica tienes, sino si esta creciendo o decreciendo.
- Hacer visible el coste al negocio. “Esta feature tarda 3 semanas en lugar de 1 porque el modulo X tiene deuda tecnica sin resolver.” Cuando la direccion entiende el coste, apoya la inversion.
La deuda tecnica como indicador de madurez
Las organizaciones maduras no son las que no tienen deuda tecnica. Son las que la conocen, la miden y la gestionan deliberadamente. Es una señal de madurez ingenieria tan reveladora como el EBITDA lo es de madurez financiera.
Si tu equipo de tecnologia no puede decirte cuanta deuda tecnica tienen y como la estan gestionando, ese es el primer problema a resolver. No porque sea una pregunta de ingenieria. Porque es una pregunta de negocio.
