Deuda técnica

La deuda técnica (también conocida como deuda de diseño [1]​ o deuda de código, pero también puede relacionarse con otros esfuerzos técnicos) es un concepto en el desarrollo de software que denota el costo implícito del retrabajo adicional causado por elegir una solución fácil en lugar de una solución que llevara más tiempo en su desarrollo e implementación.[2]​

Este concepto es similar al de "deuda monetaria" [3]​: si la deuda técnica no se paga, puede acumular 'intereses', lo que va dificultando la implementación de cambios. La deuda técnica no abordada aumenta la entropía del software. La deuda técnica no es necesariamente algo malo, y a veces, como en el caso de las pruebas de concepto, se requiere para avanzar proyectos. Algunos expertos afirman que la metáfora de la "deuda técnica" tiende a minimizar su impacto, lo que resulta en una priorización insuficiente del trabajo necesario para corregirlo.[4]​[5]​

Cuando se inicia un cambio en un software, a menudo existe la necesidad de realizar cambios coordinados en otras partes del código fuente o documentación. Los cambios requeridos que no se completen se consideran deuda y, mientras no se hagan, incurrirán en intereses, lo que dificulta la construcción del proyecto. Aunque el término se usa principalmente en el desarrollo de software, también se puede aplicar a otras profesiones.

Causas

Las causas comunes de la deuda técnica incluyen:

  • Definición inicial insuficiente, donde los requisitos todavía se están definiendo durante el desarrollo, el desarrollo comienza antes de que se lleve a cabo cualquier diseño. Esto se hace para ahorrar tiempo, pero a menudo se debe volver a trabajar más tarde.
  • Las presiones comerciales, donde la empresa considera que se publique algo antes de que se completen los cambios necesarios, acumula una deuda técnica que comprende esos cambios incompletos. [6]​: 4  [7]​: 22 
  • Falta de proceso o comprensión, donde las empresas son ciegas al concepto de deuda técnica y toman decisiones sin considerar las implicaciones.
  • Componentes estrechamente acoplados, donde las funciones no son modulares, provocando que el software no sea lo suficientemente flexible como para adaptarse a los cambios de las necesidades comerciales.
  • La falta de un conjunto de pruebas, que fomenta la reparación rápida de errores.
  • Falta de documentación, donde el código se crea sin documentación de respaldo. El trabajo para crear documentación representa deuda.[6]​
  • Falta de colaboración, donde el conocimiento no se comparte alrededor de la organización y la eficiencia del negocio se ve afectada, o los desarrolladores júnior no están debidamente orientados.
  • El desarrollo paralelo en múltiples sucursales acumula deudas técnicas debido al trabajo requerido para fusionar los cambios en una sola base de origen. Cuantos más cambios se realicen de forma aislada, más deuda.
  • Refactorización retrasada, a medida que los requisitos para un proyecto evolucionan, puede quedar claro que partes del código se han vuelto ineficientes o difíciles de editar y deben ser refactorizadas para admitir requisitos futuros. Cuanto más se demore la refactorización, y cuanto más código se agregue, mayor será la deuda. [7]​: 29 
  • Falta de alineación con los estándares, donde se ignoran las características estándar del sector, los marcos y las tecnologías. Eventualmente, la integración con los estándares vendrá, y hacerlo antes costará menos (similar a la 'refactorización retrasada'). [6]​: 7 
  • Falta de conocimiento, cuando el desarrollador no sabe cómo escribir código elegante.[7]​
  • Falta de propiedad, cuando los esfuerzos de software subcontratados dan como resultado que se requiera ingeniería interna para refactorizar o reescribir el código subcontratado.
  • Pobre liderazgo tecnológico, donde los comandos mal pensados se transmiten a la cadena de mando.
  • Cambios de especificación de última hora, estos tienen potencial para filtrarse a lo largo de un proyecto, pero no tienen tiempo ni presupuesto para llevarlos a cabo con documentación y controles.

Tipos

En un blog de discusión "Technical Debt Quadrant",[8]​ Martin Fowler distingue cuatro tipos de deuda en función de dos categorías dicotómicas: la primera categoría es imprudente frente a prudente, la segunda, deliberada frente a involuntaria.

Cuadrantes técnicos de deuda
Temerario Prudente
Deliberada "No tenemos tiempo para el diseño" "Debemos liberar ahora y lidiar con las consecuencias (más adelante)"
Inadvertida "¿Cuáles son las capas?" "Ahora sabemos cómo deberíamos haberlo hecho"

Véase también

Referencias

  1. ↑ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells (1st edición). Morgan Kaufmann. p. 258. ISBN 978-0128013977. 
  2. ↑ «Definition of the term "Technical Debt" (plus, some background information and an "explanation")». Techopedia. Consultado el 11 de agosto de 2016. 
  3. ↑ Allman, Eric (May 2012). «Managing Technical Debt». Communications of the ACM 55 (5): 50-55. doi:10.1145/2160718.2160733. 
  4. ↑ Jeffries, Ron. «Technical Debt – Bad metaphor or worst metaphor?». Archivado desde el original el 11 de noviembre de 2015. Consultado el 10 de noviembre de 2015. 
  5. ↑ Knesek, Doug. «Averting a 'Technical Debt' Crisis». Consultado el 7 de abril de 2016. 
  6. ↑ a b c Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 de noviembre de 2014). Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. p. 3. ISBN 978-0-12-801646-6. 
  7. ↑ a b c Chris Sterling (10 de diciembre de 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1. 
  8. ↑ Fowler, Martin. «Technical Debt Quadrant». Consultado el 20 de noviembre de 2014.