Los sistemas de software tienden a acumular basura , defectos internos que dificultan la modificación y expansión del sistema en comparación con el código ideal. La deuda técnica es una metáfora inventada por Ward Cunningham. Ella explica cómo percibir esta basura, por analogía con un préstamo financiero. Los esfuerzos adicionales necesarios para agregar nuevas funciones son intereses sobre el préstamo.



Imagine que en mi base de código hay un módulo de una estructura confusa. Necesito agregar una nueva característica. Si la estructura fuera clara, el trabajo llevaría cuatro días, pero con esta basura llevaría seis días. La diferencia en dos días: este es el interés de la deuda.

Lo que más me atrae de la metáfora de la deuda es una comprensión clara de los costos de servicio o eliminación. Puedo pasar cinco días limpiando la estructura modular, eliminando basura, pagando metafóricamente al "prestamista". Si hago esto para esta función, perderé porque pasaré nueve días en lugar de seis. Pero si hay dos funciones más, entonces es más rentable eliminar la basura.

Con esta formulación, la tarea se vuelve puramente matemática. Cualquier gerente con una tableta electrónica lo resolverá. Desafortunadamente, no podemos medir el rendimiento , por lo que no hay costos medibles objetivamente. Podemos estimar aproximadamente cuánto tiempo lleva desarrollar la función, cuánto tiempo llevará trabajar después de eliminar la basura, y asumir el costo de eliminarla. Pero la precisión de tales estimaciones es bastante baja.

Por lo tanto, generalmente la mejor opción es hacer lo que solemos hacer con las deudas financieras: pagar gradualmente el capital. En la primera función, pasaré un par de días adicionales para eliminar parte de la basura. Esto puede ser suficiente para reducir el interés de la deuda, de modo que en el futuro se pueda pagar en un día. Esto todavía es tiempo extra, pero con la eliminación de la basura, los cambios futuros se vuelven más baratos. La gran ventaja de la mejora incremental es que, naturalmente, pasamos más tiempo eliminando basura en áreas que cambian con frecuencia. Estas son precisamente las áreas de la base del código que más necesitan la eliminación de basura.

La comparación de los pagos de intereses con el reembolso de la deuda principal ayuda a determinar qué tipo de basura tratar. Si tengo un área particularmente terrible de la base del código, entonces el problema desaparece si resulta que no es rentable eliminar la basura. El interés se paga solo cuando tiene que trabajar con esta parte del software (la metáfora es un poco aburrida en este lugar porque siempre tiene que pagar un préstamo bancario). Por lo tanto, las áreas de código de pesadilla pero estables se pueden dejar solas.

A diferencia de las partes estables del código, las áreas de alta actividad requieren tolerancia cero para la basura porque los pagos de intereses son extremadamente altos allí. Esto es especialmente importante, ya que la basura se acumula donde los desarrolladores realizan cambios sin prestar atención a la calidad: cuantos más cambios, mayor es el riesgo de basura.

A veces se usa una metáfora de la deuda para justificar un código de baja calidad. El argumento es que el código de calidad requiere más tiempo y esfuerzo. Si necesita urgentemente nuevas funciones, es mejor hacerse cargo de la deuda y tratarla más adelante.

El peligro aquí es que a menudo este análisis es erróneo. La basura rápidamente comienza a dañar, ralentizando la introducción de nuevas funciones. Como resultado, los desarrolladores superan los límites de crédito y lanzan el producto más tarde de lo que lo harían si de inmediato pasaran tiempo proporcionando una mayor calidad. Aquí, la metáfora a menudo engaña a las personas, porque la dinámica de la deuda técnica en realidad no se corresponde con la dinámica de los préstamos financieros. Asumir la deuda para acelerar el lanzamiento del producto solo funciona si se mantiene por debajo de la línea de pago del diseño en la hipótesis de la sostenibilidad de la arquitectura , y los desarrolladores la cruzan después de unas pocas semanas, no meses.



Los debates se llevan a cabo regularmente sobre si varios tipos de basura deben considerarse deuda. Me parece que es útil tener en cuenta aquí que un deber se toma de manera consciente y razonable, o imprudentemente. Entonces apareció un cuadrado de deuda técnica .

Lectura adicional

Por lo que puedo decir, Ward introdujo este concepto por primera vez en el informe OOPSLA de 1992 . También se discutió en la wiki .

Hay una grabación de video donde Ward Cunningham discute su metáfora.

Dave Nicolette amplía la visión de Ward de la deuda técnica al proporcionar un buen ejemplo de lo que yo llamo deuda intencional razonable .

Varios lectores han sugerido otras metáforas válidas. David Panarity calificó el desarrollo de baja calidad como una escasez de programación . Aparentemente, comenzó a usar el término hace varios años cuando era consistente con la política del gobierno; Supongo que ahora es relevante nuevamente.

Scott Wood sugirió tratar la “ inflación técnica como la pérdida de suelo cuando el nivel actual de tecnología excede tanto el nivel de su producto que gradualmente se cae del medio ambiente. Los programas se quedan atrás en las versiones del lenguaje hasta el punto de que el código ya no es compatible con los compiladores principales ".

Steve McConnell destacó varios puntos buenos en la metáfora. En particular, como una reducción en la deuda no intencional deja más espacio para aceptar la deuda intencionalmente cuando es útil. También me gusta su formulación de pagos mínimos (que son demasiado altos para solucionar problemas en sistemas integrados, pero no en sitios).

Aaron Erickson habló sobre la financiación de Enron .

Henrik Kniberg argumenta que la antigua deuda técnica está causando el mayor problema y que es aconsejable establecer un techo de deuda de alta calidad para que sea más fácil de administrar.

Eric Dietrich habla sobre la pérdida humana debido a la deuda técnica : batallas en equipo, degradación de habilidades y agotamiento.

Ediciones

Esta publicación se publicó originalmente el 1 de octubre de 2003. Lo reescribí por completo en abril de 2019.