La deuda técnica es deuda real
La deuda técnica no es una metáfora abstracta. Tiene intereses que se pagan con tiempo, dinero y oportunidades perdidas. Ignorarla no la hace desaparecer.
La metáfora financiera
Ward Cunningham introdujo el término deuda técnica para explicar a no técnicos por qué a veces tiene sentido tomar atajos. Como un préstamo: obtienes algo ahora y pagas después.
La metáfora es útil pero incompleta. La deuda financiera tiene términos claros, pagos predecibles, consecuencias conocidas. La deuda técnica es más impredecible y sus intereses pueden crecer de formas que nadie anticipó.
Cómo se acumula
A veces conscientemente: sabemos que esta solución no es la mejor pero necesitamos entregar. Documentamos la deuda, planificamos pagarla.
A veces inconscientemente: no sabíamos que había una forma mejor, o el contexto cambió y lo que era apropiado dejó de serlo.
A veces por negligencia: había presión y se tomaron atajos sin pensarlo, sin documentarlo, sin plan de mejora.
El problema es que toda deuda técnica se acumula igual, independientemente de cómo llegó ahí.
Los intereses que pagas
Cada vez que alguien necesita entender código confuso, pagas intereses en tiempo.
Cada vez que un cambio simple requiere modificar múltiples lugares porque no hay abstracción adecuada, pagas intereses.
Cada vez que un bug aparece porque el código no hace obvio lo que debería pasar, pagas intereses.
Cada vez que alguien nuevo tarda más en ser productivo porque el código es difícil de entender, pagas intereses.
La deuda que no se ve
El peor tipo de deuda técnica es la invisible. Código que parece funcionar pero tiene problemas latentes. Arquitectura que escala hasta que no escala.
Esta deuda no aparece en ningún backlog, no tiene ticket asignado, nadie sabe que existe hasta que explota. Y cuando explota, el coste de arreglarla es mucho mayor que si se hubiera detectado antes.
Cuándo endeudarse tiene sentido
Para validar una idea de negocio antes de invertir en implementación perfecta. Si la idea no funciona, el código perfecto no sirve de nada.
Para aprovechar oportunidades con fecha límite. A veces llegar tarde con código perfecto es peor que llegar a tiempo con código mejorable.
Cuando el coste de la deuda es menor que el beneficio de tenerla. Esto requiere cálculo honesto, no wishful thinking.
Cómo gestionar la deuda
Documentarla explícitamente. Si no está escrita, no existe oficialmente.
Pagar regularmente. Dedicar tiempo consistente a reducir deuda, no solo cuando hay crisis.
No acumular más de la que puedes pagar. Hay un punto donde la deuda paraliza el desarrollo.
La deuda técnica no es inherentemente mala. Es una herramienta que, usada conscientemente, permite equilibrar velocidad y calidad.
El problema es cuando se acumula sin control, sin documentación, sin plan de pago. Entonces deja de ser una herramienta y se convierte en una trampa.
Trata tu deuda técnica como tratarías una deuda financiera. Con respeto, con plan, y con límites claros.