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

La primera referencia al término “deuda técnica”, en el contexto del desarrollo software, viene del año noventa y dos (acá tienes el link a aquel primer documento en que se citó la idea). Otra patentiza más de que muchos temas y términos de tendencia el día de hoy… llevaban ya muchos años con nosotros.

El autor del término fue Ward Cunningham, nombre poco popular en el campo, mas tras el que están, alén del término deuda técnica, aportaciones como el desarrollo de la primera wiki, ser uno de los firmantes el manifiesto diligente, ser uno de los vanguardistas en introducir el término patrón, y los primeros catálogos, en el planeta del desarrollo software, las viejas tarjetas CRC, contribuciones a eXtreme Programming, etcétera

Cunningham introdujo el término de deuda técnica como eufemismo que refiere al costo y también intereses que una organización debe abonar por hacer mal las cosas. El sobre esmero a abonar para sostener un mal desarrollo software, malos diseños, malas prácticas de programación, altas complejidades ciclomáticas, etcétera.

Si bien el término, originariamente, se aplicaba a malas prácticas de programación, con el tiempo su empleo se fue propagando a otras áreas, como la deuda técnica del Testing, la deuda de equipos, deuda de la arquitectura, etcétera

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

Con el tiempo, muchos otros han ido perfeccionado y ampliado el término de deuda técnica. Por poner un ejemplo, Fowler con sus 4 cuadrantes de deuda técnica. O bien, en dos mil cuatro, Joshua Kerievsky, que en Refactoring to Patterns introducía un término afín llamado “negligencia arquitectónica”. Asimismo Kruchten aportaba su definición, contextualizando, entre otros muchos, en una matriz, que te dejo más abajo, a qué refiere deuda técnica.

La matriz muestra como en contraste a los bugs o bien caídas de las aplicaciones, la deuda técnica refiere a esas cosas negativas que no se ven (desde fuera). Vamos, que cuando charlamos de deuda técnica charlamos de “caja blanca” en frente de “caja negra”.

Otro autor señalado que se ha referido al término es Steve McConnell, con su taxonomía de deuda técnica, en la que charlaba de que cuando hay deuda técnica puede ser de 2 tipos (I) Deuda incurrido de forma involuntaria debido a trabajos de baja calidad o bien (II) Deuda incurrida intencionalmente.

Los generadores de deuda técnica: desconocimiento y también procurar recortar tiempos haciendo cosas mal (o bien saltándose labores que había que haber hecho)

McConnell, coincidiendo con casi todos los autores que ha hablado de ello, marcaba ahí las 2 primordiales causas de que se produzca la deuda técnica: desconocimiento de de qué forma se deben hacer las cosas y/o buscar atajos para dar las cosas ya antes.
La falta de conocimiento está claro, no saber programar con unos mínimos de calidad, no saber unos mínimos de diseño, etcétera Los atajos, un tradicional, en frente de la presión de clientes del servicio, gerentes, usuarios, presupuestos bajos, etcétera, muchos gerentes fuerzan a los equipos a “saltarse” cualquier cosa que no sea tirar líneas de código.

De este modo, cosas como dedicar tiempo a meditar un buen diseño, las pruebas, dedicar tiempo a dejar lista la integración continua, etcétera, salen del proyecto, “consumen tiempo” y, en un corto plazo (repito, corto plazo) a ojos de mucho, con visión cortoplacista… semejan frenar en el momento de conseguir llegar a la data de entrega.

Deuda técnica a corto y largo plazo

El mayor riesgo 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.

Afirmaba Cunningham que “un poco” de deuda técnica, esa deuda técnica en un corto plazo, acelera el desarrollo, siempre y cuando se page con prontitud y no pase a ser deuda técnica en un largo plazo. El mayor riesgo 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 hoy tiene frenada a un numero demasiado alto de organizaciones, que viven el día de hoy bajo la presión de tener que ofrecer sus productos y servicios más veloz y el freno de una tecnología copada de deuda técnica de años.
Y esto te lo digo por experiencia por el hecho de que, por el hecho de que este inconveniente me lo encuentro día sí y día asimismo, demasiados años haciendo las cosas mal para salir al paso y semeja que ha llegado el bloqueo para muchos, que aun procuran a la agobiada solventarlo, procurando aplicar, por servirnos de un ejemplo, modelos diligentes, que se desmoronan 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 soportar ahí varios días.

Otra popular regla es, si usas Scrum, “limpiar” en todos y cada Esprint, lo que implica, ojo, dejar explícitamente tiempo para esto (hay aun patrones de Scrum que charlan de ello, como el Teams that Finish Early Accelerate Faster).

Y, no en balde, no olvides jamás que el ciclo de vida diligente es incremental… mas asimismo iterativo y el término iterativo está relacionado con ir “limpiando” en todos y cada iteración. Mucho ojo con el peligro de olvidarse del iterativo y quedarse solo con el acrecentar.

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

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

Salir al paso, dar algo, silenciar clientes del servicio, facturan ya antes, hacerlo lo más veloz posible si bien esté muy mal hecho, que viene a ser, tirando todavía más de símiles, esta vez de terror (te dejo unas diapositivas en slideshare en resumen el término deuda técnica con símiles de terror), como esas aquellas películas y novelas en las que el protagonista vende su ánima al demonio para salir al paso de un inconveniente, el demonio le salva…. mas tiempo después va a venir a por tu ánima.

Y acabando con un símil económico más… deseo que algún “famoso” del campo ponga de tendencia asimismo la “prima de riesgo” técnica de las compañías.

Asimismo te invitamos a

De este modo cambian las vacaciones nuestro empleo de la tecnología

Equipos dispersos: trabajo a distancia en un ambiente diligente

Los diecisiete instantes por los que vale la pena ser desarrollador

– La nueva

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

fue publicada originalmente en

turincon.net

por
Javier Garzas

.