En el desarrollo de software y otros campos de la tecnología de la información , la deuda técnica (también conocida como deuda de diseño [1] o deuda de código ) es el costo implícito de la futura reelaboración requerida al elegir una solución fácil pero limitada en lugar de un mejor enfoque que podría llevar más tiempo. [2]
De manera análoga a la deuda monetaria , [3] si la deuda técnica no se paga, puede acumular "intereses", lo que dificulta la implementación de cambios. La deuda técnica no abordada aumenta la entropía del software y el costo de reelaboración adicional. De manera similar a la deuda monetaria, la deuda técnica no es necesariamente algo malo y, a veces (por ejemplo, como prueba de concepto) es necesaria para hacer avanzar los proyectos. Por otro lado, algunos expertos afirman que la metáfora de la “deuda técnica” tiende a minimizar las ramificaciones, lo que resulta en una priorización insuficiente del trabajo necesario para corregirla. [4] [5]
Cuando se inicia un cambio en una base de código, a menudo existe la necesidad de realizar otros cambios coordinados en otras partes de la base de código o la documentación. Los cambios requeridos que no se completan se consideran deuda y, hasta que se paguen, generarán intereses además de los intereses, lo que dificulta la construcción de un proyecto. Aunque el término se utiliza principalmente en el desarrollo de software, también se puede aplicar a otras profesiones.
En un seminario de Dagstuhl celebrado en 2016, la deuda técnica fue definida por expertos académicos e industriales en el tema de la siguiente manera: "En sistemas intensivos en software, la deuda técnica es un conjunto de estructuras de diseño o implementación que son convenientes en el corto plazo, pero que establecen "La deuda técnica presenta un pasivo real o contingente cuyo impacto se limita a las cualidades internas del sistema, principalmente la mantenibilidad y la evolución". [6]
Las causas comunes de deuda técnica incluyen:
Kenny Rubin utiliza las siguientes categorías de estado: [10]
Los "pagos de intereses" se deben tanto al necesario mantenimiento local como a la falta de mantenimiento por parte de otros usuarios del proyecto. El desarrollo continuo del proyecto upstream puede aumentar el costo de "pagar la deuda" en el futuro. [ se necesita aclaración ] Uno salda la deuda simplemente completando el trabajo incompleto. [ cita necesaria ]
La acumulación de deuda técnica es una de las principales causas de que los proyectos no cumplan con los plazos. [ cita necesaria ] Es difícil estimar exactamente cuánto trabajo es necesario para pagar la deuda. Por cada cambio que se inicia, se compromete al proyecto una cantidad incierta de trabajo incompleto. La fecha límite no se cumple cuando el proyecto se da cuenta de que hay más trabajo incompleto (deuda) del que hay tiempo para completarlo. Para tener cronogramas de lanzamiento predecibles, un equipo de desarrollo debe limitar la cantidad de trabajo en progreso para mantener la cantidad de El trabajo incompleto (o la deuda) es pequeño en todo momento. [ cita necesaria ]
Si se completa suficiente trabajo en un proyecto como para no presentar una barrera para la presentación, entonces se lanzará un proyecto que aún conlleva una cantidad sustancial de deuda técnica. Si este software llega a producción, entonces los riesgos de implementar futuras refactorizaciones que puedan abordar la deuda técnica aumentan dramáticamente. La modificación del código de producción conlleva el riesgo de interrupciones, pérdidas financieras reales y posiblemente repercusiones legales si los contratos involucran acuerdos de nivel de servicio (SLA). Por esta razón, podemos ver la transferencia de deuda técnica a la producción casi como si fuera un aumento en la tasa de interés y el único momento en que esta disminuye es cuando los despliegues se rechazan y se retiran.
"A medida que un programa en evolución cambia continuamente, su complejidad, que refleja el deterioro de su estructura, aumenta a menos que se trabaje para mantenerla o reducirla". [11]
—Meir Manny Lehman , 1980
Si bien la Ley de Manny Lehman ya indicaba que los programas en evolución aumentan continuamente su complejidad y deterioran su estructura a menos que se trabaje para mantenerlos, Ward Cunningham fue el primero en establecer la comparación entre complejidad técnica y deuda en un informe de experiencia de 1992:
"Enviar código por primera vez es como endeudarse. Un poco de deuda acelera el desarrollo siempre y cuando se pague rápidamente con una reescritura... El peligro ocurre cuando la deuda no se paga. Cada minuto invertido en un código que no es del todo correcto cuenta como intereses sobre esa deuda. Organizaciones de ingeniería enteras pueden quedar paralizadas bajo la carga de la deuda de una implementación no consolidada, orientada a objetos o de otro tipo." [12]
- Ward Cunningham , 1992
En su texto de 2004, Refactoring to Patterns , Joshua Kerievsky presenta un argumento comparable sobre los costos asociados con la negligencia arquitectónica, que describe como "deuda de diseño". [13]
Las actividades que podrían posponerse incluyen documentación , redacción de pruebas , atención a los comentarios TODO y abordar las advertencias del compilador y del análisis de código estático . Otros casos de deuda técnica incluyen conocimiento que no se comparte en la organización y código que es demasiado confuso para modificarlo fácilmente. [ cita necesaria ]
Al escribir sobre el desarrollo de PHP en 2014, Junade Ali dijo:
El costo de no pagar nunca esta deuda técnica es claro; eventualmente, el costo de ofrecer funcionalidad será tan lento que será fácil para un producto de software competitivo bien diseñado superar al software mal diseñado en términos de características. En mi experiencia, el software mal diseñado también puede generar una fuerza laboral de ingeniería más estresada, lo que a su vez genera una mayor rotación de personal (lo que a su vez afecta los costos y la productividad al entregar funciones). Además, debido a la complejidad de una base de código determinada, la capacidad de estimar con precisión el trabajo también desaparecerá. En los casos en que las agencias de desarrollo cobran característica por característica, el margen de ganancias por la entrega de código eventualmente se deteriorará.
— Junade Ali escribe en Dominar los patrones de diseño PHP [14]
Grady Booch compara cómo las ciudades en evolución son similares a los sistemas en evolución con uso intensivo de software y cómo la falta de refactorización puede generar deuda técnica.
"El concepto de deuda técnica es fundamental para comprender las fuerzas que pesan sobre los sistemas, ya que a menudo explica dónde, cómo y por qué un sistema está bajo estrés. En las ciudades, las reparaciones de la infraestructura a menudo se retrasan y se realizan cambios incrementales en lugar de cambios audaces. Lo mismo ocurre nuevamente en los sistemas con uso intensivo de software, los usuarios sufren las consecuencias de una complejidad caprichosa, mejoras retrasadas y cambios incrementales insuficientes; los desarrolladores que desarrollan tales sistemas sufren las dificultades de no poder escribir código de calidad porque siempre lo hacen. tratando de alcanzarlo." [1]
— Grady Booch , 2014
En el software de código abierto , posponer el envío de cambios locales al proyecto upstream es una forma de deuda técnica. [ cita necesaria ]