Deuda técnica, el coste de no programar bien

La deuda técnica es un concepto del desarrollo de software muy importante en calidad, ya que muestra de forma sencilla el coste de no haber seguido las buenas prácticas.

El término de deuda técnica podemos decir que nace hace ya casi 30 años, pues es un artículo de Ward Cunningham en 1992, la primera vez que se hace referencia a él.

En dicho artículo, habla sobre el desarrollo de WyCASH+, un sistema de gestión de portfolios que según afirman, fue el primer software comercial desarrollado bajo los principios de Extreme Programming.

Así, cuenta como el inicio del desarrollo de una aplicación, empieza a generar una deuda, que debe resolverse posteriormente para poder mantenerla.

Puedes leer el artículo original aquí: The WyCash Portfolio Management System

¿Qué es la deuda técnica?

La deuda técnica es una metáfora que hace referencia a la deuda económica.

De la misma forma que cuando te prestan dinero, generas una deuda, no seguir las prácticas adecuadas en el desarrollo de software, hace que generes esta “deuda técnica”

Así como en la deuda económica debes devolver dinero, en la deuda técnica debes devolver sobretodo tiempo (sí, que en el fondo es dinero)

Y tienes que devolver ese tiempo ya que cuando no hacemos buen código, tenemos dos opciones, dejarlo así (y ya te imaginas el resultado a medio/largo plazo) o solucionarlo y mantenerlo (para que pueda ser mantenible y escalable)

Deuda técnica

Siguiendo la analogía de la deuda económica, uno de sus puntos negativos, es que debe devolverse con intereses, que crecerán conforme perdure el tiempo en saldarla.

Por otro lado, siempre hay alguien que pagará esa deuda. En el caso de la deuda técnica, primero debe pagarla el desarrollador, pero si no lo hace, acabará pagándola el cliente o usuario del software.

¿Por qué se genera la deuda técnica?

Según afirma el mismo Ward Cunningham en su artículo, al empezar a desarrollar, ya se empieza a generar algo de deuda.

Pero esa pequeña deuda, es la que permite entregar el producto de forma más rápida. Por lo que se puede deducir que un poco de deuda no es malo, o que incluso es necesario para poder agilizar las entregas.

Pero, por desgracia, en la mayoría de los casos, esa deuda crece cada vez más convirtiéndose en inasumible por desarrollador, cliente y/o usuario, lo que lleva a una bancarrota a ese software.

Así, en este último caso, los motivos suelen ser:

Plazos no realistas

En un afán muchas veces inconmensurable de superar a la competencia, o de conseguir un cliente/proyecto, se pactan objetivos y plazos que no son posibles de cumplir si se debe realizar un trabajo de calidad.

Requisitos difusos

En otros casos, la falta de unos requisitos concretos, lleva al mal entendimiento del producto que se debe realizar, y, en consecuencia, a un desarrollo errático que debe resolverse. En este caso, suele también afectar a la infraestructura necesaria para la explotación de la aplicación

Presupuesto

Uno de los factores más repetidos, aunque muchas veces quizá confuso. La falta de presupuesto deriva en equipos inadecuados (tanto de personas como de infraestructura), y relacionado con el primer motivo, en plazos que no deben extenderse.

Falta de inspección de código

A nivel de software, es muy importante analizar el código, pues permite identificar deficiencias sin causar problemas por haberse ejecutado. Por lo tanto, la falta de éstas inspecciones, hará que código con deuda llegue al repositorio, y posteriormente al cliente/usuario

Falta de calidad de procesos

La deuda técnica no se refiere simplemente al software, también está relacionado con la infraestructura, por lo que una falta de definición y seguimiento correcto de los procesos, deriva también en no seguir las buenas prácticas de las que siempre hablamos.

Sistemas heredados

Lo que, por desgracia, suele ser en la mayoría de los casos. Pocas veces tenemos la ocasión de empezar un proyecto desde 0, y si la deuda técnica suele aumentar conforme aumenta el tiempo empleado y el tamaño de un proyecto, con el código heredado, también nos llega un buen paquete de deuda “de regalo”.

¿Cómo evitar la deuda técnica?

Pues si un proyecto empieza por una definición de requisitos, y por exigencia/organización del cliente, una estimación de plazos, esa sería la primera línea de defensa para minimizar la deuda.

Fíjate que hablo de minimizar, no de evitar, pues como decía antes, un poco de deuda no es negativo, y deberías aprender a convivir con ella.

De esta forma, unos objetivos realistas, y la disponibilidad de los recursos necesarios para cumplirlos, se convierten en imprescindibles para realizar un software de calidad en primera instancia.

Por otro lado, es importantísimo la buena predisposición del equipo de personas que tenga que llevarlo a cabo. Igual que el mejor equipo puede realizar muy poco con escasos recursos, los mejores recursos serían inútiles para un equipo desmotivado y/o que no quiera realizar las cosas bien.

Y hablando de recursos, uno muy importante sería disponer de herramientas que ayudaran, tanto a evitar deuda técnica, como a medirla para tenerla bajo control.

Si me sueles leer, sabes que me gusta SonarQube, y una de sus características es lo sencillo que muestra la deuda técnica de un proyecto.

Para ello, a cada code smell (defecto o mala práctica relacionado con la mantenibilidad) que detecta, le asigna un tiempo estimado de solución (que suele ser breve, el problema viene cuando tenemos muchos)

Así, el porcentaje de deuda técnica, es el resultado del tiempo necesario para solucionar esos code smells, entre el tiempo empleado total en el desarrollo del proyecto.

Además, para facilitar su asimilación, divide el tiempo total en jornadas de 8 diarias, o semanas de 40 horas, con lo que se obtiene como resultado los días laborables necesarios para solucionarlo.

Deuda tecnica SonarQube

La ventaja de este indicador, es conocer de forma sencilla, los casos en los que, ante algunos proyectos heredados, es más recomendable arreglarlos o empezarlos de nuevo.

Así que, como resumen, quiero recalcar la importancia de hacer las cosas bien desde el principio, de medir esa deuda técnica y, aunque no se puede/debe evitar, minimizarla lo máximo posible y saber convivir con ella

Fuentes:

Imágenes:

Poster vector created by macrovector – www.freepik.com
Business vector created by iconicbestiary – www.freepik.com

Deja un comentario