Reevaluando el concepto de deuda técnica
El autor sostiene que la metáfora de deuda técnica no refleja la realidad del mantenimiento de código y propone centrarse en la fricción y el riesgo.
En cada proyecto surge la frase: "tenemos demasiada deuda técnica". Todos la aceptan sin medirla. El autor intentó cuantificarla y descubrió que la metáfora está mal construida.
El modelo bancario no cabe
Si la deuda técnica fuera un préstamo, tendría capital, intereses y un plan de amortización. En la práctica, no existe un número concreto: un módulo puede ser calificado de diferente forma por tres desarrolladores, y no hay contrato que lo defina. Además, la mayoría de la deuda surge por factores externos (bibliotecas abandonadas, reglas de negocio cambiantes o proyectos heredados) y no por decisiones conscientes de “acortar camino”.
Intereses que solo aparecen cuando se toca el código
En los bancos los intereses se acumulan mensualmente. En el código, el “interés” aparece solo cuando se modifica una pieza problemática. Un archivo grande y activo puede costar tres semanas de trabajo, mientras que un archivo poco usado puede permanecer intacto durante años sin generar coste alguno.
La deuda no se paga
A diferencia de un préstamo, la deuda técnica no tiene un pago final. Cada refactorización que se realiza hoy se volverá obsoleta en un futuro próximo. El autor concluye que el término genera culpa innecesaria y distrae de los objetivos reales.
Enfoque basado en fricción y riesgo
En lugar de hablar de “deuda”, el autor sugiere medir la fricción: cuántos días extra se tarda en implementar una nueva funcionalidad sobre un módulo. También se debe hablar de riesgo: una dependencia no parcheada puede no costar nada hasta que cause un fallo crítico.
Qué podemos hacer
- Priorizar cambios que generan fricción: los archivos que cambian con frecuencia y afectan a la velocidad de entrega deben ser revisados.
- Permitir que el código “duerma”: los archivos que no se tocan pueden permanecer tal cual, aun si son poco elegantes.
- Revisar la arquitectura antes de nuevas características: si una función prevista para Q3 no es posible con la arquitectura actual, se debe comunicar el riesgo.
Conclusión
La deuda técnica, tal como se usa comúnmente, no es un préstamo que se pueda saldar. Es la brecha entre el código escrito ayer y el mundo que avanza. Cambiemos el discurso: hablemos de fricción y riesgo, no de saldos y intereses.
Para más detalles, puedes leer el artículo completo en Dev.to.
