Usuario:Afrachel/Taller
La deuda técnica, también conocida como deuda de diseño o deuda de código, es un concepto de desarrollo de software que hace referencia a los costos de un esfuerzo adicional causado por la elección de una solución sencilla, aunque limitada, en lugar de usar una mejor que tomaría más tiempo.[1][2]
Definición[editar]
El sector informático presenta la particularidad de que permite la implementación de productos no acabados o con errores conocidos. En ocasiones, la política de ahorro de costes en la implementación de hardware o el desarrollo de software se centra en recortar los procesos de pruebas, control de calidad o documentación, o incluso algunos parámetros básicos de optimización de procesos, lo que compromete la viabilidad a largo plazo del proyecto a cambio de poder entregarlo en el plazo previsto y con el presupuesto acordado.
Una diferencia fundamental entre los errores (conocidos como bugs, en inglés) y la deuda técnica es que, mientras que los errores afectan al funcionamiento de la aplicación, la deuda técnica se refiere exclusivamente a aquellos errores en la codificación que, pese a que no afectarán al funcionamiento de la misma, dificultan su mantenimiento, ampliación, despliegue o desarrollos posteriores, por ser código desarrollado con malas prácticas como la duplicidad o la ausencia de una correcta refactorización.
Tipos[editar]
En el artículo de opinión "Cuadrante de Deuda Técnica"[3], Martin Fowler distingue cuatro tipos de deudas basadas en dos categorías dicotómicas: la primera categoría es imprudente contra prudente, la segunda es deliberado contra inadvertido.
| Imprudente | Prudente | |
|---|---|---|
Deliberado |
"No tenemos tiempo para el diseño" | "Debemos despachar ahora y lidiar con las consecuencias (después)" |
Inadvertido |
"¿Qué son las capas?" | "Ahora sabemos cómo deberíamos de haberlo hecho" |
Causas[editar]
- Definición previa insuficiente. Ocurre cuando los requerimientos continúan siendo definidos durante el desarrollo y el proceso de construcción da inicio antes de ser diseñado.
- Presión del área de negocio. Cuando el área de negocio considera que se debe liberar el desarrollo antes de que todos los cambios necesarios sean completados, generando así una deuda técnica.[4]
- Falta de procesos o entendimiento. Cuando el área de negocio desconoce el concepto de deuda técnica y toman decisiones apresuradas sin considerar las implicaciones.
- Componentes fuertemente acoplados. Ocurre cuando las funcionalidades no son modulares y la solución no es lo suficiente flexible para adaptarse a las nuevas necesidades de negocio.
- Falta de una batería de pruebas, que propicia el uso de parches improvisados y riesgos para corregir errores de código.
- Falta de documentación, cuando se escribe código sin la documentación adecuada de soporte. El esfuerzo que representa la generación de documentación representa una deuda que debe pagarse en algún momento.
- Falta de colaboración, cuando el conocimiento no es compartido dentro de la organización y la eficiencia del negocio se tambalea o los desarrolladores junior no están capacitados adecuadamente.
- Desarrollo en paralelo en dos o más ramas incrementa la deuda técnica ya que el trabajo requerido para fusionar los cambios en una sola línea base de código. Entre más cambios se realicen de manera aislada más incrementa la deuda.
- Posponer la refactorización. A medida que los requerimientos del proyecto evolucionan las partes de código que se han vuelto ineficientes y difíciles de editar deben ser mejorados (refactorizados) para poder soportar futuros requerimientos. Entre más tiempo se posponga la refactorización y más código sea agregado más grande será la deuda.
- Falta de alineación a los estándares, ocurre cuando los estándares de la industria, las tecnologías y los marcos de trabajo son ignorados.
- Falta de conocimiento, cuando los desarrolladores simplemente no saben cómo escribir código elegante.
- Falta de pertenencia, cuando los esfuerzo del desarrollo de software realizado por terceros necesita ser refactorizado o reescrito por los desarrolladores internos.
- Liderazgo técnico pobre, ocurre cuando se toman decisiones mal pensadas y éstas se transmiten a través de la cadena de mando.
- Cambio de especificación de último minuto, estos tienen el potencial de filtrarse a lo largo de un proyecto, pero no hay tiempo ni presupuesto para llevarlos a cabo con la documentación y los controles necesarios.
Consecuencias[editar]
El resultado de esta política implica que el desarrollo del software se prolonga en el tiempo más allá de la entrega del producto supuestamente concluido; incluso en ocasiones son distintos equipos de desarrollo los que acaban haciéndose cargo de las mejoras. Si el proyecto estaba delimitado en fases, la subsanación de errores de las fases más tempranas se solaparía con el desarrollo de las siguientes fases, lo que dificulta llevar a buen término ambas tareas. Lo mismo es aplicable para el despliegue de hardware o tareas equivalentes.
Origen del término[editar]
El término deuda técnica fue propuesto por primera vez en 1992 por Ward Cunningham.[1] Un desarrollo pobre, tal y como se describe en el párrafo anterior, equivale a una evaluación de inversiones financieras basada en la obtención de beneficios a corto plazo. En el sector de las finanzas, una inversión que busca el beneficio a corto plazo puede generar deudas cuyos intereses se han de liquidar durante un período de tiempo muy prolongado. De forma análoga, un desarrollo tecnológico aparentemente corto puede requerir un esfuerzo extra para subsanar los problemas generados al no aplicar los consejos básicos de desarrollo. Ese esfuerzo extra, que puede multiplicar el tiempo de desarrollo del proyecto inicial, equivaldría a los intereses de una deuda financiera.
Véase también[editar]
- Crisis del software
- Gran bola de lodo
- El Mítico Hombre-Mes
- Entropía del software
- Pudrición del software
- Fragilidad del software
- Principio de Peter del software
- Leyes de Lehman de la evolución del software
Enlaces externos[editar]
- Ward explains what debt metaphor is from youtube(video) and C2.com(transcript)
Referencias[editar]
- ↑ a b «The WyCash Portfolio Management System». c2.com. Consultado el 14 de octubre de 2020.
- ↑ «What is Technical Debt? - Definition from Techopedia». Techopedia.com (en inglés). Consultado el 14 de octubre de 2020.
- ↑ Fowler, Martin. «Technical Debt Quadrant». Consultado el 20 November 2014.
- ↑ Chris Sterling (10 December 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 19. ISBN 978-0-321-70055-1.
[[Categoría:Metáforas]] [[Categoría:Arquitectura de software]] [[Categoría:Ingeniería de software]] [[Categoría:Mantenimiento del software]] [[Categoría:Eufemismos]]