La deuda técnica (también conocida como deuda de codificación ) es una metáfora de la ingeniería de software que se refiere a los problemas acumulados en el código o la arquitectura del software asociados con el descuido de la calidad en el desarrollo del software y que causa costos laborales adicionales en el futuro. La deuda técnica suele ser invisible para los usuarios finales del producto, pero está asociada con deficiencias en la mantenibilidad , la capacidad de prueba, la comprensibilidad, la modificabilidad y la portabilidad . Por analogía con la deuda financiera , la deuda técnica puede crecer demasiado con " intereses ", lo que dificulta (o incluso imposibilita) continuar con el desarrollo, el tiempo adicional que los desarrolladores dedican a cambiar un producto de software, corregir errores, mantener, etc. Aunque un aumento en La deuda técnica generalmente afecta negativamente el futuro del proyecto, también puede ser una decisión de compromiso consciente dictada por las circunstancias.
Por sí mismo, el código defectuoso no siempre es una deuda técnica, ya que el daño ("interés sobre la deuda") proviene de la necesidad de cambiar el código con el tiempo [1] .
El término deuda técnica se utiliza principalmente en relación con el desarrollo de software, pero también se puede aplicar a otras áreas de la ingeniería.
A veces, el término se usa incorrectamente, denotando código heredado que ya no es compatible , que es de mala calidad y fue escrito por otra persona [1] .
Causas comunes de la deuda técnica (puede haber varias) [2] :
Los “pagos de intereses” aparecen tanto durante el desarrollo local como en ausencia de apoyo técnico de otros desarrolladores de proyectos. El desarrollo continuo del proyecto puede aumentar el costo del trabajo de "reembolso de la deuda" en el futuro. La deuda técnica se paga simplemente completando el trabajo en curso.
La acumulación de deuda técnica es una de las principales causas de los retrasos en los proyectos. Es difícil estimar exactamente cuánto trabajo se necesita hacer para pagar la deuda. Con cada cambio, se agrega una cantidad indefinida de trabajo en curso al proyecto. Los plazos se “queman” cuando el proyecto llega a entender que todavía hay mucho más trabajo en curso (deuda) que tiempo para completarlo. Para tener calendarios de lanzamiento predecibles, el equipo de desarrollo debe limitar la cantidad de trabajo que se realiza a un nivel que minimice la cantidad de trabajo en curso (deuda técnica).
Si bien la Ley de complejidad creciente de Manny Lehman ya había demostrado que el desarrollo constante de los programas aumenta su complejidad y degrada su diseño mientras se trabaja en ellos, Ward Cunningham hizo por primera vez la comparación entre complejidad técnica y deuda en un informe de 1992:
En su artículo de 2004 "Refactorización con patrones", Joshua Kerievsky aboga por una comparación del costo de abordar la mala práctica arquitectónica, que describe como "deuda estructural" [5] .
Las acciones que se pueden retrasar incluyen documentación, pruebas de escritura, prestar atención a los comentarios marcados como "TODO", luchar contra el compilador y advertencias sobre el análisis de código estático . Otros casos de deuda técnica incluyen una base de conocimiento que no se comparte dentro de una organización y un código que es demasiado complejo para cambiarlo fácilmente.
En el software de código abierto, retrasar la presentación de cambios locales al proyecto principal es una deuda técnica. .