Este artículo es una traducción sobre la deuda técnica escrita por Martin Fowler, Versión En inglés.
Tienes una pieza de funcionalidad que necesitas agregar a tu sistema. Vez dos formas de hacerlo, una es hacerlo rápido pero es confuso – Sabes que esto traerá cambios más difíciles en el futuro. La otra opción es un diseño limpio, pero tomará más tiempo realizarlo.
La deuda técnica es una metáfora maravillosa desarrollada por Ward Cunningham para ayudarnos a pensar acerca de este problema. En esta metáfora, hacer las cosas de forma rápida y sucia nos prepara para la deuda técnica, que es similar a una deuda financiera. Tal como una deuda financiera, la deuda técnica incurre en pagos de intereses, que vienen en forma de esfuerzo extra que tenemos que hacer en desarrollos futuros debido a la elección rápida y sucia. Podemos escoger seguir pagando los intereses, o podemos pagar un inicial refactorizando el diseño rápido y sucio en un mejor diseño. A pesar de tener un costo inicial alto al principio, ganamos por la reducción de pagos de intereses en el futuro.
Esta metáfora también explica por qué puede ser sensato hacer el enfoque rápido y sucio. Así como un negocio incurre en alguna deuda para tomar ventaja de una oportunidad de mercado, los desarrolladores pueden incurrir en una deuda técnica para cumplir un deadline importante. El problema más común es que las empresas de desarrollo de software dejan su deuda fuera de control y gastan más en futuros esfuerzos de desarrollo pagando intereses desangrantes.
Lo difícil de la deuda técnica, es por supuesto que a diferencia del dinero ésta es imposible de medir efectivamente. Los pagos de interés hieren la productividad del equipo, pero como no podemos medir la productividad, realmente no podemos ver el verdadero efecto de nuestra deuda técnica.
Una cosa que es fácilmente olvidada es que tu sólo haces dinero endeudándote. El costo más grande de la deuda técnica es el hecho de que ralentiza tu habilidad de entregar funcionalidades futuras, por lo que te da un costo de oportunidad por la pérdida de ingresos. Además siguiendo la Hipótesis de resistencia de diseño, necesitas entregar antes de alcanzar la línea de pago del diseño que te da una oportunidad ganar algo en tu deuda. A menudo la deuda técnica termina ralentizandote tanto que entregas más tarde.
La deuda técnica viene con varias fuentes, algunas pueden ser buenas y otras malas, Yo uso el Cuadrante de la deuda técnica para describirlas.
(Por lo que puedo decir, Ward fue el primero en introducir el concepto en un reporte de experiencia para OOPSLA 1992. También ha sido discutido en la wiki.)
Lecturas adicionales
Ward Cunningham tiene una video charla donde él discute la metáfora que creó.
Un par de lectores enviaron algunos nombres igualmente buenos. David Panariti se refiere a la programación fea como programación de déficit. Aparentemente él originalmente lo empezó a usar hace unos años cuando este se ajustaba con las políticas gubernamentales; Supongo que es natural otra vez hoy en día.
Scott Wood sugiere el término «Inflación técnica que puede ser vista como el terreno perdido cuando el nivel actual de tecnología sobrepasa a la fundación de su producto en la medida en que comienza a perder compatibilidad con la industria. Ejemplos de esto podría quedarse atrás en las versiones de un lenguaje hasta el punto en que tu código no es compatible con los compiladores principales.»
Steve McConnell saca varios puntos buenos en la metáfora, particularmente cómo mantener tu deuda no intencionada te da más espacio para intencionalmente asumir la deuda cuando sea útil hacerlo. También me gusta su noción de pagos mínimos (que son altos para arreglar problemas con sistemas embedidos en contraposición a sitios web).
Aaron Erickson habla acerca del financiamiento enron (sobre el escándalo de la desaparecida empresa enron, leer su artículo en wikipedia).
Henrik Kniberg argumenta que las deudas técnicas viejas causan los problemas más grandes y que es sabio un techo de deuda cualitativo para administrarlo.
Erik Dietrich discute el costo humano de la deuda técnica: luchas internas de equipo, habilidades atrofiadas y desgaste.
Notas finales (Santiago Bernal): Considero oportuno como desarrollador de software, conocer la deuda técnica, y explicársela a los clientes cuando se esté discutiendo los términos cruciales de un proyecto (tiempo, alcance y costo) para poder tener un acuerdo claro y evitar dolores de cabeza (o pago de intereses).