La deuda técnica (también conocida como deuda de diseño [1] o deuda de código , pero también puede estar relacionada con otros esfuerzos técnicos) es un concepto en el desarrollo de software que refleja el costo implícito de reprocesamiento adicional causado al elegir una solución fácil (limitada) ahora en su lugar de utilizar un mejor enfoque que llevaría más tiempo. [2]
Al igual que con la deuda monetaria , [3] si la deuda técnica no se paga, puede acumular "intereses", lo que dificulta la implementación de los cambios. La deuda técnica no resuelta aumenta la entropía del software . 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) se requiere 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 se traduce en una priorización insuficiente del trabajo necesario para corregirla. [4] [5]
A medida que 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.
Causas
Las causas comunes de la deuda técnica incluyen:
- El desarrollo continuo, una larga serie de mejoras del proyecto a lo largo del tiempo, hace que las soluciones antiguas sean subóptimas.
- Definición inicial insuficiente, donde los requisitos aún 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 es necesario modificarlo más tarde.
- Las presiones comerciales, en las que la empresa considera publicar algo antes de que se completen los cambios necesarios, genera 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 , el software no es lo suficientemente flexible para adaptarse a los cambios en las necesidades comerciales.
- La falta de un banco de pruebas , lo que fomenta rápidas y arriesgadas ayuda de banda correcciones de errores.
- Falta de documentación, donde el código se crea sin documentación de respaldo. El trabajo de crear documentación representa una deuda. [6]
- Falta de colaboración, donde el conocimiento no se comparte en la organización y la eficiencia empresarial se ve afectada, o los desarrolladores junior no reciben la orientación adecuada.
- El desarrollo paralelo en múltiples sucursales genera deuda técnica debido al trabajo requerido para fusionar los cambios en una base de fuente única. Cuantos más cambios se hagan de forma aislada, más deuda.
- Refactorización retrasada ; A medida que evolucionan los requisitos de un proyecto, puede quedar claro que partes del código se han vuelto ineficientes o difíciles de editar y deben refactorizarse para admitir requisitos futuros. Cuanto más se retrasa la refactorización y cuanto más código se agrega, mayor es la deuda. [7] : 29
- Falta de alineación con los estándares, donde se ignoran las características, marcos y tecnologías estándar de la industria . Con el tiempo llegará la integración con los estándares, 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.
- Liderazgo tecnológico deficiente, donde los comandos mal pensados se transmiten a lo largo de la cadena de mando.
- Los cambios de especificación de último momento tienen el potencial de filtrarse a lo largo de un proyecto, pero no hay tiempo ni presupuesto para llevarlos a cabo con documentación y controles.
Servicio o pago de la deuda técnica
Kenny Rubin usa las siguientes categorías de estado: [8]
- Deuda técnica derivada: deuda que el equipo de desarrollo desconocía que existía hasta que se expuso durante el curso normal de la realización del trabajo en el producto. Por ejemplo, el equipo está agregando una nueva característica al producto y, al hacerlo, se da cuenta de que alguien que ya se había ido hace mucho tiempo había construido una solución alternativa en el código.
- Deuda técnica conocida: deuda que es conocida por el equipo de desarrollo y que se ha hecho visible mediante uno de los enfoques analizados anteriormente.
- Deuda técnica focalizada: deuda que se conoce y que el equipo de desarrollo ha fijado como objetivo para su servicio.
Consecuencias
Los "pagos de intereses" son causados tanto por el mantenimiento local necesario como por la ausencia de mantenimiento por parte de otros usuarios del proyecto. El desarrollo continuo del proyecto upstream puede aumentar el costo de "saldar la deuda" en el futuro. [ aclaración necesaria ] Uno paga la deuda simplemente completando el trabajo incompleto. [ cita requerida ]
La acumulación de deuda técnica es una de las principales causas de que los proyectos no cumplan con los plazos. [ cita requerida ] 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 se incumple cuando el proyecto se da cuenta de que hay más trabajo incompleto (deuda) que 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 Trabajo incompleto (o deuda) pequeño en todo momento. [ cita requerida ]
Si se completa suficiente trabajo en un proyecto 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, los riesgos de implementar futuros refactores que puedan abordar la deuda técnica aumentan drásticamente. La modificación del código de producción conlleva el riesgo de interrupciones, pérdidas financieras reales y posibles repercusiones legales si los contratos implican acuerdos de nivel de servicio (SLA). Por esta razón, podemos ver el traspaso de la deuda técnica a la producción casi como si se tratara de un aumento en la tasa de interés y la única vez que esto 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 la estructura, aumenta a menos que se haga un trabajo para mantenerlo o reducirlo". [9]
- Meir Manny Lehman , 1980
Si bien la Ley de Manny Lehman ya indicaba que los programas en evolución aumentan continuamente su complejidad y su estructura en deterioro a menos que se haga un trabajo para mantenerlos, Ward Cunningham primero hizo la comparación entre la complejidad técnica y la deuda en un informe de experiencia de 1992:
"Enviar el código por primera vez es como endeudarse. Un poco de deuda acelera el desarrollo siempre y cuando se reembolse rápidamente con una reescritura ... El peligro ocurre cuando la deuda no se paga. Cada minuto gastado en un código incorrecto 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 ". [10]
- Ward Cunningham , 1992
En su texto de 2004, Refactorización de patrones , Joshua Kerievsky presenta un argumento comparable sobre los costos asociados con la negligencia arquitectónica, que describe como "deuda de diseño". [11]
Las actividades que pueden posponerse incluyen documentación , redacción de pruebas , atención a los comentarios de TODO y abordar las advertencias de análisis de código estático y del compilador . Otros casos de deuda técnica incluyen el conocimiento que no se comparte en la organización y el código que es demasiado confuso para ser modificado fácilmente. [ cita requerida ]
Al escribir sobre el desarrollo de PHP en 2014, Junade Ali dijo:
El costo de no pagar nunca esta deuda técnica es claro; Con el tiempo, el costo de entregar la funcionalidad será tan lento que es fácil que un producto de software competitivo bien diseñado supere al software mal diseñado en términos de características. En mi experiencia, el software mal diseñado también puede conducir a 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 por función, el margen de beneficio para la entrega del código se deteriorará con el tiempo.
- Junade Ali escribe en Mastering PHP Design Patterns [12]
Grady Booch compara cómo la evolución de las ciudades es similar a la evolución de los sistemas intensivos en software y cómo la falta de refactorización puede conducir a una 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é se tensiona un sistema. En las ciudades, las reparaciones en la infraestructura a menudo se retrasan y se realizan cambios incrementales en lugar de audaces . Así sucede de nuevo en los sistemas con uso intensivo de software. Los usuarios sufren las consecuencias de la complejidad caprichosa, las mejoras demoradas y los cambios incrementales insuficientes; los desarrolladores que desarrollan tales sistemas sufren las trampas y flechas de nunca poder escribir código de calidad porque siempre están tratando de ponerse al día ". [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 requerida ]
Ver también
- Olor de código (síntomas de calidad de código inferior que pueden contribuir a la deuda técnica)
- Gran bola de barro
- Código de espagueti
- Podredumbre de software
- Cirugía de escopeta
- Factor de bus
- Escala de compromiso
- Entropía de software
- VENTA
- Costo hundido
- TODO, FIXME, XXX
- Sobreingeniería
Referencias
- ↑ a b Suryanarayana, Girish (noviembre de 2014). Refactorización para olores de diseño de software (1ª ed.). Morgan Kaufmann. pag. 258. ISBN 978-0128013977.
- ^ "Definición del término" Deuda Técnica "(más, algunos antecedentes y una" explicación ")" . Techopedia . Consultado el 11 de agosto de 2016 .
- ^ Allman, Eric (mayo de 2012). "Gestión de la deuda técnica". Comunicaciones de la ACM . 55 (5): 50–55. doi : 10.1145 / 2160718.2160733 .
- ^ Jeffries, Ron. "Deuda técnica - ¿Mala metáfora o peor metáfora?" . Archivado desde el original el 11 de noviembre de 2015 . Consultado el 10 de noviembre de 2015 .
- ^ Knesek, Doug. "Evitar una crisis de 'deuda técnica'" . Consultado el 7 de abril de 2016 .
- ^ a b c Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 de noviembre de 2014). Refactorización para olores de diseño de software: gestión de la deuda técnica . Ciencia de Elsevier. pag. 3. ISBN 978-0-12-801646-6.
- ^ a b c Chris Sterling (10 de diciembre de 2010). Gestión de la deuda de software: construcción para un cambio inevitable (Adobe Reader) . Addison-Wesley Professional. pag. 17. ISBN 978-0-321-70055-1.
- ^ Rubin, Kenneth (2013), Scrum esencial. Una guía práctica para el proceso ágil más popular , Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
- ^ Lehman, MM (1996). "Leyes de la evolución del software revisadas" . EWSPT '96 Actas del 5º taller europeo sobre tecnología de procesos de software : 108–124 . Consultado el 19 de noviembre de 2014 .
- ^ Ward Cunningham (26 de marzo de 1992). "El sistema de gestión de cartera WyCash" . Consultado el 26 de septiembre de 2008 .
- ^ Kerievsky, Joshua (2004). Refactorización de patrones . ISBN 978-0-321-21335-8.
- ^ Ali, Junade (septiembre de 2016). Dominar los patrones de diseño PHP | Libros PACKT (1 ed.). Birmingham, Inglaterra, Reino Unido: Packt Publishing Limited. pag. 11. ISBN 978-1-78588-713-0. Consultado el 11 de diciembre de 2017 .
enlaces externos
- Ward explica la metáfora de la deuda , video de Ward Cunningham
- OnTechnicalDebt La comunidad en línea para discutir la deuda técnica
- Entrevistas de expertos en deuda técnica: Ward Cunningham , Philippe KRUCHTEN , Ipek OZKAYA , Jean-Louis LETOUZEY
- Steve McConnell habla sobre la deuda técnica
- Deuda técnica de Martin Fowler Bliki
- Evitando una crisis de "deuda técnica" por Doug Knesek
- "¡Salga de la deuda técnica ahora!" , una charla de Andy Lester
- Ley de Lehman
- Seminario web sobre gestión de la deuda técnica por Steve McConnell
- Boundy, David, Cáncer de software: las siete señales de alerta temprana o aquí , Notas de ingeniería de software de ACM SIGSOFT, vol. 18 No. 2 (abril de 1993), Association for Computing Machinery, Nueva York, Nueva York, EE. UU.
- Deuda técnica: Investeer en voorkom faillissement por Colin Spoel
- Deudas técnicas: todo lo que necesita saber
- ¿Qué es la deuda técnica? del blog de DeepSource