Deuda técnica

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 futuras modificaciones porque una solución prioriza la conveniencia sobre el diseño a largo plazo. ^[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 volver a trabajar en ella. 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 da como resultado una priorización insuficiente del trabajo necesario para corregirla. ^{[4] [5]}

A medida que se inicia un cambio en una base de código, suele ser necesario realizar otros cambios coordinados en otras partes de la base de código o la documentación. Los cambios necesarios que no se completan se consideran deuda y, hasta que se paguen, generarán intereses sobre otros intereses, lo que hace que sea complicado desarrollar 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, los expertos académicos e industriales en la materia definieron la deuda técnica de la siguiente manera: "En los sistemas con uso intensivo de software, la deuda técnica es un conjunto de construcciones de diseño o implementación que son convenientes a corto plazo, pero que crean un contexto técnico que puede hacer que los cambios futuros sean más costosos o imposibles. La deuda técnica presenta una responsabilidad real o contingente cuyo impacto se limita a las cualidades internas del sistema, principalmente la capacidad de mantenimiento y evolución". ^[6]

La deuda técnica postula que un diseño conveniente reduce esencialmente los gastos en el presente, pero genera gastos adicionales en el futuro. Esta premisa hace suposiciones sobre el futuro:

• Que el producto sobreviva el tiempo suficiente para realmente incurrir en los costos futuros
• Que los acontecimientos futuros no hagan obsoleto el diseño "a largo plazo" tan pronto como el diseño conveniente
• Que los avances futuros no hagan que la reelaboración sea menos costosa que las suposiciones actuales

Como el futuro es incierto, es posible que una deuda técnica percibida hoy en día pueda parecer en realidad un ahorro en el futuro. Aunque el escenario de la deuda se considera más probable, la incertidumbre complica aún más las decisiones de diseño.

Además, el cálculo de la deuda técnica normalmente considera el costo del tiempo de trabajo de los empleados, pero una evaluación completa debe incluir otros costos incurridos o diferidos por la decisión de diseño, como capacitación, licencias, herramientas, servicios, hardware, costo de oportunidad, etc.

Las causas comunes de deuda técnica incluyen:

• El desarrollo continuo y las largas series de mejoras del proyecto a lo largo del tiempo hacen que las soluciones antiguas no sean óptimas.
• Definición inicial insuficiente, en la que los requisitos se siguen definiendo durante el desarrollo; el desarrollo comienza antes de que se realice cualquier diseño. Esto se hace para ahorrar tiempo, pero a menudo es necesario volver a trabajarlo más adelante. ^[7]
• Presiones comerciales, donde la empresa considera lanzar algo antes de que se completen los cambios necesarios, por lo tanto, acumula deuda técnica relacionada con esos cambios incompletos. ^{[8] : 4  [9] : 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 del negocio.
• Falta de un conjunto de pruebas , lo que fomenta correcciones rápidas y arriesgadas de errores.
• Falta de documentación del software , donde el código se crea sin documentación de respaldo. El trabajo para crear la documentación representa una deuda. ^[8]
• Falta de colaboración, donde el conocimiento no se comparte en toda la organización y la eficiencia del negocio se ve afectada, o los desarrolladores junior no reciben la orientación adecuada.
• El desarrollo paralelo en varias ramas genera deuda técnica debido al trabajo necesario para fusionar los cambios en una única base de origen. Cuantos más cambios se realicen de forma aislada, mayor será la deuda.
• Refactorización diferida : a medida que evolucionan los requisitos de un proyecto, puede resultar evidente que partes del código se han vuelto ineficientes o difíciles de editar y deben refactorizarse para cumplir con los requisitos futuros. Cuanto más se demore la refactorización y cuanto más código se agregue, mayor será la deuda. ^{[9] : 29}
• Falta de alineación con los estándares, donde se ignoran las características, los marcos y las tecnologías estándar de la industria. Con el tiempo, la integración con los estándares llegará y hacerlo antes costará menos (similar a la "refactorización retrasada"). ^{[8] : 7}
• Falta de conocimiento, cuando el desarrollador no sabe cómo escribir código elegante. ^[9]
• Falta de propiedad, cuando los esfuerzos de software subcontratado dan como resultado que se requiera ingeniería interna para refactorizar o reescribir el código subcontratado.
• Liderazgo tecnológico deficiente, en el que se transmiten órdenes mal pensadas a lo largo de la cadena de mando.
• Cambios de última hora en las especificaciones. Estos cambios pueden extenderse a lo largo de un proyecto, pero no se dispone de tiempo ni presupuesto suficientes para documentarlos y probarlos. ^[7]
• Pereza, donde los empleados podrían no estar dispuestos o incentivados a poner un esfuerzo extra en la legibilidad y documentación del código.

Kenny Rubin utiliza las siguientes categorías de estado: ^[10]

• Deuda técnica que surge por casualidad: deuda que el equipo de desarrollo desconocía hasta que se descubrió durante el curso normal 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 se fue hace mucho tiempo había incorporado una solución alternativa al código años antes.
• Deuda técnica conocida: deuda que el equipo de desarrollo conoce y que se ha hecho visible mediante uno de muchos enfoques.
• Deuda técnica objetivo: deuda que se conoce y que el equipo de desarrollo ha decidido pagar.

Los "pagos de intereses" se deben tanto al mantenimiento local necesario como a la ausencia de mantenimiento por parte de otros usuarios del proyecto. El desarrollo continuo en el proyecto aguas arriba puede aumentar el costo de "liquidar 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 saldar la deuda. Por cada cambio que se inicia, se asigna al proyecto una cantidad incierta de trabajo incompleto. Se incumple la fecha límite 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 curso para mantener baja la cantidad de trabajo incompleto (o deuda) en todo momento. ^{[ cita requerida ]}

Si se completa suficiente trabajo en un proyecto como para no presentar un obstáculo 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 drásticamente. Modificar el código de producción conlleva el riesgo de interrupciones, pérdidas financieras reales y posiblemente repercusiones legales si los contratos implican acuerdos de nivel de servicio (SLA). Por esta razón, podemos ver el traslado de la deuda técnica a producción casi como si fuera un aumento en la tasa de interés y la única vez que esto disminuye es cuando se rechazan y se retiran las implementaciones.

"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. Una pequeña deuda acelera el desarrollo siempre que se pague con prontitud mediante una reescritura... El peligro surge cuando la deuda no se paga. Cada minuto que se gasta en un código que no es del todo correcto cuenta como interés de esa deuda. Organizaciones de ingeniería enteras pueden quedar paralizadas por 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 él describe como "deuda de diseño". ^[13]

Las actividades que podrían posponerse incluyen la documentación , la redacción de pruebas , la atención a los comentarios de TODO y la resolución de las advertencias del compilador y del análisis de código estático . Otros casos de deuda técnica incluyen el conocimiento que no se comparte en toda la organización y el código que es demasiado confuso para modificarlo 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 funcionalidad se volverá 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 características). Además, debido a la complejidad de una base de código dada, la capacidad de estimar el trabajo con precisión también desaparecerá. En los casos en que las agencias de desarrollo cobran función por función, el margen de ganancia por entregar código eventualmente se deteriorará.

—  Junade Ali escribe en Mastering PHP Design Patterns ^[14]

Grady Booch compara cómo la evolución de las ciudades es similar a la evolución de sistemas 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é se estresa un sistema. En las ciudades, las reparaciones de la infraestructura suelen demorarse y se realizan cambios incrementales en lugar de audaces. Lo mismo sucede en los sistemas que hacen un uso intensivo del software. Los usuarios sufren las consecuencias de una complejidad caprichosa, mejoras demoradas y cambios incrementales insuficientes; los desarrolladores que desarrollan dichos sistemas sufren los problemas de no 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 original es una forma de deuda técnica. ^{[ cita requerida ]}

• Mal olor del código (síntomas de una calidad de código inferior que pueden contribuir a la deuda técnica)
• Gran bola de barro
• Factor de bus
• Escalada del compromiso
• Manufacturación
• Sobreingeniería
• Cirugía de escopeta
• Entropía del software
• Podredumbre del software
• Código espagueti
• Escala
• Costo hundido
• TODO, ARREGLAME, XXX

• 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 a expertos sobre 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
• Cómo evitar una crisis de “deuda técnica” por Doug Knesek
• "¡Sal de la deuda técnica ahora!", charla de Andy Lester
• Ley de Lehman
• Seminario web sobre gestión de deuda técnica a cargo de Steve McConnell
• Boundy, David, Cáncer de software: las siete señales de advertencia tempranas o aquí, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (abril de 1993), Association for Computing Machinery, Nueva York, Nueva York, EE. UU.
• Deuda técnica: inversor en voorkom faillissement por Colin Spoel
• Deudas técnicas: Todo lo que necesitas saber
• ¿Qué es la deuda técnica? del blog de DeepSource