Idea principal

No todo lo que se llama deuda técnica lo es. Un código mal estructurado, una arquitectura débil, una complejidad conocida desde hace años, un riesgo latente: son incomodidades. Existen, pesan, no llevan ningún vencimiento y nadie las paga en una fecha.

La deuda aparece en el momento en que la empresa decide saldar. Es esa decisión la que crea el objeto: fija un importe — el coste de tratamiento —, un beneficiario y un momento. Antes de ella no hay nada que inscribir; después de ella hay un tema de producto como otro cualquiera, comparable con las funcionalidades y arbitrable junto a ellas.

El desencadenante habitual de esa decisión es un vuelco de coste: la incomodidad pasa a ser más cara de soportar que de tratar — porque bloquea una estrategia, ralentiza mucho al equipo, expone a un riesgo, degrada la calidad percibida por el cliente, o impide un cambio de producto importante.

Por qué es importante

Desactiva una conversación que gira en círculos entre desarrolladores y producto. Mientras la deuda se presenta como un estado del código, se discute en términos de limpieza, y producto no tiene ningún agarre. Recalificada como decisión de saldo, se discute en términos de coste y se vuelve arbitrable.

También explica por qué los inventarios de deuda casi nunca producen trabajo: recensan incomodidades, y una incomodidad no le pide nada a nadie.

Matices y límites

La recalificación tiene su reverso: da a producto el derecho a no decidir nunca, y por tanto a dejar que un riesgo se acumule hasta convertirse en un incidente. La incomodidad no tratada no es gratis, simplemente no está contada.

Y el vuelco de coste es difícil de establecer antes de que se manifieste — la ralentización del equipo se constata mejor a posteriori que en el momento en que habría que decidir.

Preguntas abiertas

• ¿Qué señales anuncian el vuelco de coste lo bastante pronto para que la decisión de saldar preceda al incidente?