La metáfora de la deuda técnica la propuso Ward Cunningham para explicar a directivos no técnicos por qué había que dedicar tiempo a reescribir código que ya funcionaba.
La idea: cuando eliges una solución rápida en lugar de la correcta, obtienes velocidad ahora y contraes una deuda. Esa deuda genera intereses, que se pagan en forma de mayor esfuerzo en cada cambio posterior. Y como toda deuda, puede ser razonable —a veces conviene entregar ya— siempre que sea consciente y se amortice.
Llevo tiempo pensando que el concepto se queda corto si se limita al código, porque el mismo mecanismo opera en casi todo lo demás.
Deuda de procedimiento
Un procedimiento se diseña para un contexto. El contexto cambia y el procedimiento no. Se le añade una excepción, luego otra, luego una instrucción interna que matiza la excepción anterior.
Al cabo de unos años tienes algo que nadie diseñó, que solo funciona porque hay gente que conoce las tres excepciones, y donde cualquier modificación tiene efectos imprevisibles. Los intereses de esa deuda se pagan cada vez que entra alguien nuevo, cada vez que hay que automatizar algo y cada vez que se comete un error que el diseño original habría evitado.
Deuda de conocimiento
Cada vez que resolvemos algo y no lo documentamos, contraemos deuda. Funciona igual: ahora es más rápido no escribirlo, y el interés se paga en las decenas de interrupciones futuras a la persona que lo sabe, en el tiempo de quien tiene que reconstruirlo y en el riesgo de que esa persona se vaya.
Esta es probablemente la deuda más común y la peor contabilizada, porque su coste no aparece en ningún sitio: se diluye en interrupciones de cinco minutos.
Deuda de datos
Un campo que se empezó a usar para otra cosa. Una tabla con tres formas distintas de escribir el mismo municipio. Una fecha almacenada como texto. Un histórico que arrastra una migración mal hecha de hace ocho años.
Los intereses de esta deuda se descubren tarde y de golpe: el día que alguien quiere explotar esos datos y resulta que no se puede sin un trabajo de limpieza que nadie presupuestó.
Deuda de formación
Cuando se implanta un sistema y se forma justo lo imprescindible para que arranque, se contrae deuda. La gente aprende el camino mínimo y desconoce el resto. Los intereses se pagan en uso ineficiente, en errores recurrentes y en una percepción de la herramienta peor que la herramienta.
Por qué esto importa
Porque el vocabulario financiero, que puede sonar a artificio, resulta muy útil para tener la conversación con quien decide.
Permite decir: esto lo podemos entregar en marzo con una solución provisional, y eso nos costará aproximadamente tanto durante los próximos años. O bien lo hacemos en junio y no pagamos ese interés. Ninguna de las dos opciones es obviamente mejor; depende de cuánto valga entregar en marzo.
Lo que no es defendible es tomar la primera opción sin saber que se está tomando. Y eso es lo que ocurre casi siempre: la deuda se contrae por defecto, sin decisión explícita, y sin que nadie la anote en ningún sitio.
Lo que he visto funcionar
Anotarla. Una lista visible de decisiones provisionales, con la fecha y el motivo. No hace falta más ceremonia. El simple hecho de que exista la lista cambia la conversación, porque convierte algo difuso en una acumulación medible.
Reservar capacidad de forma fija. Un porcentaje del tiempo del equipo dedicado a amortizar, protegido igual que se protege una entrega. Sin eso, siempre habrá algo más urgente, y la deuda solo crece.
Y amortizar donde duele. No toda la deuda merece pagarse: hay código feo que nadie va a tocar nunca y procedimientos malos que van a desaparecer. La deuda que hay que atacar es la que está en el camino de lo que vas a hacer los próximos meses.
El resto puede seguir ahí. Pero conviene saber que está.