La metáfora de la “deuda técnica”

Genbeta Dev by Javier Garzas

La primera referencia al concepto “deuda técnica”, en el contexto del desarrollo software, viene del año 92

(aquí tienes el enlace a aquel primer documento en que se citó la idea). Otra evidencia más de que muchos
temas y términos de moda hoy... llevaban ya muchos años con nosotros.

El creador del término fue Ward Cunningham, nombre poco popular en el sector, pero tras el que están, más
allá del concepto deuda técnica, aportaciones como el desarrollo de la primera wiki, ser uno de los firmantes

el manifiesto ágil, ser uno de los pioneros en introducir el concepto patrón, y los primeros catálogos, en el
mundo del desarrollo software, las antiguas tarjetas CRC, contribuciones a eXtreme Programming, etc.

Cunningham introdujo el concepto de deuda técnica como eufemismo que refiere al coste e intereses que una

organización tiene que pagar por hacer mal las cosas. El sobre esfuerzo a pagar para mantener un mal
desarrollo software, malos diseños, malas prácticas de programación, altas complejidades ciclomáticas, etc..
Aunque el concepto, originariamente, se aplicaba a malas prácticas de programación, con el tiempo su uso se

fue extendiendo a otras áreas, como la deuda técnica del Testing, la deuda de equipos, deuda de la
arquitectura, etc.

Deuda técnica, esas cosas mal hechas que no se ven “desde fuera”…

Con el tiempo, muchos otros han ido perfeccionado y ampliado el concepto de deuda técnica. Por ejemplo,

Fowler con sus cuatro cuadrantes de deuda técnica. O, en 2004, Joshua Kerievsky, que en Refactoring to

Patterns introducía un concepto similar llamado “negligencia arquitectónica”. También Kruchten aportaba su

definición, contextualizando, entre otros, en una matriz, que te dejo más abajo, a qué refiere deuda técnica.

La matriz muestra como a diferencia de los bugs o caídas de las aplicaciones, la deuda técnica refiere a esas

cosas negativas que no se ven (desde fuera). Vamos, que cuando hablamos de deuda técnica hablamos de
“caja blanca” frente a “caja negra”.

Otro autor destacado que se ha referido al término es Steve McConnell, con su taxonomía de deuda técnica,

en la que hablaba de que cuando hay deuda técnica puede ser de dos tipos (I) Deuda incurrido
involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrida intencionalmente.

Los generadores de deuda técnica: desconocimiento e intentar recortar tiempos haciendo cosas mal (o saltándose
tareas que había que haber hecho)
McConnell, coincidiendo con prácticamente todos los autores que ha hablado de ello, marcaba ahí las dos

principales causas de que se genere la deuda técnica: desconocimiento de cómo se deben hacer las cosas

y/o buscar atajos para entregar las cosas antes. El desconocimiento está claro, no saber programar con unos

mínimos de calidad, no saber unos mínimos de diseño, etc. Los atajos, un clásico, frente a la presión de

clientes, gerentes, usuarios, presupuestos bajos, etc., muchos gerentes fuerzan a los equipos a “saltarse”
cualquier cosa que no sea tirar líneas de código.

Así, cosas como dedicar tiempo a pensar un buen diseño, las pruebas, dedicar tiempo a dejar lista la

integración continua, etc., salen del proyecto, “consumen tiempo” y, a corto plazo (repito, corto plazo) a ojos
de mucho, con visión cortoplacista... parecen frenar a la hora de lograr llegar a la fecha de entrega.

Deuda técnica a corto y largo plazo

El mayor peligro viene de esa deuda técnica que no se paga y va quedando ahí, de esa deuda técnica que
lleva ahí años, esa por la que ya han pasado muchos veranos.

Decía Cunningham que “un poco” de deuda técnica, esa deuda técnica a corto plazo, acelera el desarrollo,

siempre que se page con prontitud y no pase a ser deuda técnica a largo plazo. El mayor peligro viene de esa

deuda técnica que no se paga y va quedando ahí, de esa deuda técnica que lleva ahí años, esa por la que ya
han pasado muchos veranos.

Esa acumulación de deuda técnica de años es la que a día de hoy tiene frenada a un numero demasiado alto

de organizaciones, que viven hoy bajo la presión de tener que ofrecer sus productos y servicios más rápido y

el freno de una tecnología copada de deuda técnica de años. Y esto te lo digo por experiencia porque, porque

este problema me lo encuentro día sí y día también, demasiados años haciendo las cosas mal para salir al
paso y parece que ha llegado el bloqueo para muchos, que incluso intentan a la desesperada solucionarlo,
intentando aplicar, por ejemplo, modelos ágiles, que se derrumban al enfrentarse a la deuda técnica.

¿Y cuanto es corto plazo en deuda técnica?

Henrik Kniberg, autor de “Scrum and XP from the trenches”, que en su experiencia las cosas mal hechas solo
debería aguantar ahí unos cuantos días.

Otra popular regla es, si utilizas Scrum, “limpiar” en cada Sprint, lo que implica, ojo, dejar explícitamente

tiempo para ello (hay incluso patrones de Scrum que hablan de ello, como el Teams that Finish Early
Accelerate Faster).
Y, no en vano, no olvides nunca que el ciclo de vida ágil es incremental... pero también iterativo y el concepto

iterativo está relacionado con ir “limpiando” en cada iteración. Mucho ojo con el riesgo de olvidarse del
iterativo y quedarse solo con el incrementar.

Esa visión cortoplacista, que es como vender el alma al diablo

Hay muchas causas por las que se general deuda técnica, desconocimiento, no querer mirarlo, etc. Pero hay
uno que para mi es mucho más preocupante: una visión de negocio (ya no hablo técnica) cortoplacista.

Salir al paso, entregar algo, acallar clientes, facturan antes, hacerlo lo más rápido posible aunque esté muy

mal hecho, que viene a ser, tirando aún más de símiles, esta vez de terror (te dejo unas diapositivas en

slideshare resumiendo el concepto deuda técnica con símiles de terror), como esas aquellas películas y

novelas en las que el protagonista vende su alma al diablo para salir al paso de un problema, el diablo le
salva.... pero tiempo después vendrá a por tu alma.

Y terminando con un símil económico más... estoy deseando que algún “famoso” del sector ponga de moda
también la “prima de riesgo” técnica de las empresas.