Deuda técnica

La deuda técnica es el trabajo extra que un equipo va a tener que hacer más adelante por una decisión más rápida y desprolija que toma ahora. El programador Ward Cunningham inventó la metáfora en 1992 para explicárselo a gerentes no técnicos: sacar código imperfecto es como pedir plata prestada. Conseguís algo antes, pero pagás intereses: cada cambio futuro en esa zona lleva más tiempo y se rompe más fácil, hasta que devolvés el capital ordenando lo que quedó mal.

La deuda no es mala por definición. Una startup que está probando si alguien quiere su producto puede, con razón, cortar camino, igual que un negocio toma un crédito para crecer. El problema es la deuda que nadie registra. Se acumula por muchos lados: plazos apurados, código copiado y pegado, tests que faltan, librerías viejas, un diseño inicial que ya no encaja con lo que el producto terminó siendo, o simplemente gente que se fue sin documentar nada.

Se nota cuando pedidos simples empiezan a tardar semanas, cuando cada arreglo trae dos bugs nuevos o cuando una sola persona se anima a tocar cierto módulo. Los equipos la manejan anotándola en el backlog, reservando parte de cada ciclo para pagarla y haciendo refactoring sobre la marcha. Si se ignora mucho tiempo, el sistema puede volverse tan caro de cambiar que reescribirlo de cero parece tentador, lo cual es una apuesta riesgosa en sí misma.