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

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

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.