Qué es la deuda técnica, explicada sin tecnicismos
Tus desarrolladores hablan de 'deuda técnica' y tú asientes. Aquí va qué significa de verdad y por qué deberías tomártela en serio aunque no toques código.
Si tienes software y un equipo técnico, tarde o temprano alguien te dirá que hay que parar a 'pagar deuda técnica'. Suena a excusa para no sacar lo que pediste. Casi nunca lo es.
La deuda técnica es lo que pasa cuando, para llegar a tiempo, se hace algo de la forma rápida en vez de la forma buena. Igual que pedir dinero prestado, a veces es la decisión correcta. Lanzas antes, validas la idea, ganas mercado. El problema viene si no devuelves nunca lo que pediste, porque entonces empiezan a llegar los intereses.
Esos intereses se notan así: cada nueva función tarda más que la anterior. Lo que antes se cambiaba en un día ahora lleva una semana y rompe dos cosas por el camino. El equipo está cada vez más nervioso al tocar ciertas zonas. Cuando ves esos síntomas, lo fácil es pensar que tu gente trabaja peor. Casi siempre es otra cosa: la factura acumulada de atajos viejos que nadie devolvió.
Lo incómodo de la deuda técnica es que es invisible desde fuera. El producto se ve igual de bien la semana que está limpio por dentro que la semana antes de venirse abajo. Por eso es tan fácil ignorarla hasta que un día algo crítico se rompe en el peor momento posible.
No toda la deuda hay que pagarla, igual que no toda deuda financiera conviene amortizar. Si una parte del código es fea pero no la tocas nunca y funciona, déjala en paz. Lo que sí merece la pena es arreglar lo que tocáis a menudo, porque ahí los intereses se pagan cada semana.
Como dueño no necesitas entender el código. Sí necesitas entender que cuando el equipo pide tiempo para esto, normalmente te está avisando de un coste que ya estás pagando sin verlo. Ignorarlo no lo hace desaparecer, solo lo aplaza con recargo.