Un sprint que no produce ningún botón nuevo, ninguna página nueva, nada que un cliente vaya a ver jamás, es una de las partidas más difíciles de aprobar para el dueño de un negocio — parece pagar por nada. Casi nunca lo es. Suele ser la factura que vence por un atajo tomado meses antes para cumplir un plazo que en ese momento importaba más que el código de debajo.
La analogía del préstamo, hecha concreta
La deuda técnica es exactamente lo que parece: un préstamo contra la velocidad de desarrollo futura, contraído para avanzar más rápido hoy. Una función construida de la forma rápida en lugar de la duradera se lanza antes, lo cual suele ser la decisión correcta bajo un plazo real — pero, como cualquier préstamo, acumula intereses. Cada función futura que toca esa misma parte del sistema tarda más en construirse, porque el desarrollador primero tiene que sortear el atajo en lugar de construir limpiamente sobre terreno firme.
Por qué no aparece en una hoja de ruta como las funciones
Una función nueva tiene una demo. Una corrección de errores tiene un antes y un después. Pagar la deuda técnica no tiene ninguna de las dos — el resultado visible de hacerlo bien es que todo lo construido después va más rápido y falla menos, lo cual es invisible por definición, porque la alternativa (que las cosas sigan lentas y rotas) nunca le ocurrió a nadie para poder compararla. Esa invisibilidad es exactamente lo que la convierte en la partida más fácil de recortar de una hoja de ruta bajo presión, y exactamente lo que, al recortarla repetidamente, convierte un préstamo manejable en uno que realmente perjudica al negocio.
El tipo de interés no es el mismo en todas partes
No toda la deuda técnica cuesta lo mismo de mantener. Un atajo en un rincón estable y poco tocado del sistema puede quedarse quieto durante años sin costar nada significativo, mientras que el mismo tipo de atajo en la parte del sistema por la que tiene que pasar cada función nueva se acumula rápido — cada trabajo no relacionado se vuelve más lento por su culpa. La pregunta útil no es "cuánta deuda técnica tenemos" en abstracto, sino "qué deuda concreta está en el camino de lo que construimos a continuación", porque esa es la que realmente merece pagarse ahora.
Cómo se ve "pagarla" en concreto
Es reescribir una pieza de código que funciona pero es frágil, para que las próximas tres funciones construidas cerca de ella no hereden esa fragilidad. Es sustituir una solución manual que un equipo repetía en silencio cada semana por algo automatizado. Es desenredar una dependencia que hacía que un tipo concreto de cambio tardara el triple de lo que debería, cada vez. Nada de esto es glamuroso, y todo se traduce más tarde en funciones que se lanzan más rápido de lo que lo habrían hecho de otro modo.
Cómo saber si realmente merece la pena hacerlo ahora
La prueba honesta es simple: ¿esta deuda concreta está frenando ahora mismo trabajo real y planificado, o es orden teórico sin coste a corto plazo? La primera merece priorizarse incluso sin un entregable visible que mostrar; la segunda normalmente puede esperar, porque no toda deuda necesita pagarse de inmediato — solo la que está gravando activamente lo próximo que estás construyendo.
Esto forma parte de la misma conversación que comprar, construir o configurar — el coste a largo plazo de un sistema no es solo lo que costó construirlo, es lo que cuesta seguir construyendo encima de él.
Nuestro equipo de software señala la deuda técnica en el momento en que se crea y presupuesta explícitamente su pago, para que sea una decisión visible y planificada, no un impuesto silencioso que nadie aceptó.
