SCRUM

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)

La deuda técnica se genera por:

• Definición previa insuficiente. Ocurre cuando los requerimientos continuan siendo definidos durante el desarrollo y el proceso de construcción da inicio antes de ser diseñado.
• Presión del área de negocio. Cuando el área de negocio considera que se debe liberar el desarrollo antes de que todos los cambios necesarios sean completados, generando así una deuda técnica.
• Falta de procesos o entendimiento. Cuando el área de negocio desconoce el concepto de deuda técnica y toman decisiones apresuradas sin considerar las implicaciones.
• Componentes fuertemente acoplados. Ocurre cuando las funcionalidades no son modulares y la solución no es lo suficiente flexible para adaptarse a las nuevas necesidades de negocio.
• Falta de una batería de pruebas, que propicia el uso de parches improvisados y riesgosos para corregir errores de código.
• Falta de documentación, cuando se escribe código sin la documentación adecuada de soporte. El esfuerzo que representa la generación de documentación representa una deuda que debe pagarse en algún momento.
• Falta de colaboración, cuando el conocimiento no es compartido dentro de la organización y la eficiencia del negocio se tambalea o los desarrolladores junior no están capacitados adecuadamente.
• Desarrollo en paralelo en dos o más ramas incrementa la deuda técnica ya que el trabajo requerido para fusionar los cambios en una sola línea base de código. Entre más cambios se realicen de manera aislada más incrementa la deuda.
• Posponer la refactorización. A medida que los requerimientos del proyecto evolucionan las partes de código que se han vuelto ineficientes y dificiles de editar deben ser mejorados (refactorizados) para poder soportar futuros requerimientos. Entre más tiempo se posponga la refactorización y más código sea agregado más grande será la deuda.
• Falta de alineación a los estándares, ocurre cuando los estándares de la industria, las tecnologías y los marcos de trabajo son ignorados.
• Falta de conocimiento, cuando los desarrolladores simplemente no saben cómo escribir código elegante.
• Falta de pertenencia, cuando los esfuerzo del desarrollo de software realizado por terceros necesita ser refactorizado o reescrito por los desarrolladores internos.
• Liderazgo técnico pobre, ocurre cuando se toman decisiones mal pensadas y éstas se transmiten a través de la cadena de mando.
• Cambio de especificación de último minuto, estos tienen el potencial de filtrarse a lo largo de un proyecto, pero no hay tiempo ni presupuesto para llevarlos a cabo con la documentación y los controles necesarios.

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.