Deuda técnica

El otro día me encontraba paseando con Harvey, un border collie de seis meses que se convirtió en mi nuevo mejor amigo después de que en diciembre tuviéramos que decir adios a nuestro anterior compañero. No tenía intención de irme muy lejos de casa, pero el inusual buen tiempo de esa tarde de "no verano" y la necesidad de quemar las energías de este incansable cánido, invitaba a seguir caminando.

Llevaba cerca de 20 minutos deambulando sin rumbo fijo, cuando me di cuenta que la tira de una de las sandalias estaba fallando. No me pareció suficiente riesgo para abortar ese plácido paseo, por lo que modifiqué mi forma de andar, suponiendo que eso iba a disminuir el problema, y continué andando.

No pasaron los 100 metros cuando la tira cedió del todo y solo entonces mi cerebro se dio cuenta que no podía continuar con mi travesía. Tirando del perro con una mano y balanceando el pie, con la intención de que en cada paso la sandalia quedase debajo de su planta, no vi más opción que volver a casa descalzo.

Ese espectáculo de balanceo "podal" debía ser tan grotesco, que un par de chicas latinoamericanas que estaban haciendo deporte me dieron el alto. No debería ser importante la procedencia, pero como para algunos cuando son malas acciones les parece necesario indicarlo, pues ahora que es una buena acción me parece justo hacer lo propio.

—Agárrate la sandalia con un par de "coletas" y así por lo menos podrá llegar a casa — Me dijo una de ellas. Y acercándose a mí, me dio un par de gomas de pelo.

Maravillado por la ocurrencia y anestesiado por un repentino aumento de esperanza en la bondad humana, "parcheé" la sandalia y me dirigí a casa.

El truco parecía que funcionaba, la sandalia se sentía robusta y firme al paso, cada paso que daba no parecía indicar que fuera el último, tanto es así, que cuando estaba cerca de casa me animé a seguir caminando y di otra vuelta a la manzana. Se podría decir que me gusta el riesgo, aunque otros dirían que a eso se llama ser un insensato.

Ya a la noche, cuando tocaba sacar la basura y dar el último paseo al perro, buscando algo cómodo y rápido que ponerme de calzado, vi aquellas sandalias en la entrada y mi cabeza tonteó con la posibilidad de volver a ponérmelas. No os voy a confesar lo que hice, pero ese simple tonteo me motivo escribir este artículo.

Y esta anécdota me lleva a hablaros de la deuda técnica. En proyectos software se entiende como deuda técnica al coste añadido sobre el proyecto por elegir una solución más sencilla, en lugar de otra opción que pueda llevar más tiempo pese a ser la correcta.

Con el fin de garantizar la calidad del producto, disponemos de herramientas de análisis estático (y dinámico) de código que se encargan de medirlo. Para ello se basan en determinados indicadores como: el acoplamiento del código, la falta de test unitarios o de comentarios, el tamaño de los ficheros de código o la complejidad ciclomática, para calcularlo. Un ejemplo de este tipo de herramientas es: SonarQube.

La deuda técnica no siempre es medible o conocida, una mala arquitectura o no seguir estándares, frameworks o normativas nos pueden llevar a acumular deuda en nuestro producto. En otras ocasiones es conocida y asumida, el arreglo de un bug o cubrir una necesidad de una forma que sabemos que no es la adecuada (ñapa), van sumando también deuda a nuestro producto.

Pero el precio a pagar no es solo el tiempo que llevaría solucionar el problema concreto, si no el coste adicional que tendremos en el resto del ciclo de vida del producto por elegir en un momento ese camino fácil. Porque amigos, esta deuda, como en cualquier economía macro o micro, tiene intereses y llega un momento en que se vuelve insostenible e imposible de pagar.

Es por esto, por lo que es conveniente detectar y resolver los incidentes que nos causan esa deuda lo antes posible. Las herramientas no ayudan a analizar cuál es estado del producto durante su construcción y definir "Quality Gates" que nos permiten marcar umbrales a ciertos indicadores y adelantar su detección.

Pero no todo es medible ni cuantificable. Somos los responsables de los proyectos, junto con los ingenieros de calidad, los que tenemos que gestionar esa deuda. Para ello es importante priorizar los cambios detectados en aquellos que proporcionen mayor valor según su criticidad.

Otra tarea, seguramente la más complicada, es hacer ver, a nuestros superiores, usuarios o clientes, el coste en intereses de no ir pagándola. La deuda es ese concepto que nos ayuda a explicar la necesidad de refactorizar y de invertir en el desarrollo de un producto de calidad desde el inicio.

Las consecuencias pueden ser impredecibles, nunca sabremos qué hubiera pasado si hubiera usado las sandalias de nuevo en ese último paseo, ni los intereses que hubiera tenido que pagar por ese parche mal hecho si las siguiera utilizando. Por si acaso, sigo manteniendo las sandalias en la entrada, quizás en algún otro artículo acabe volviendo a esta historia.

¿Tienes algún truco para hacer ver la importancia de esta deuda técnica? ¿Hay algún cambio pendiente que hace que cada incidencia detectada tardes el doble en identificar o solucionar? ¿Hablamos? Comparte tu experiencia.