La deuda técnica (technical debt) en el desarrollo de software

Sonar gira alrededor del concepto de deuda técnica, de hecho su lema es: “Put your technical debt under control”.

Dado que en mi organización hemos implantado hace poco tiempo Sonar, me interesé en conocer qué significaba eso de deuda técnica y una vez que comprendí a que se refería, me pareció un concepto muy a tener en cuenta, ya que resume en solo dos palabras muchas de las sensaciones que tengo cuando se está realizando el mantenimiento (o el desarrollo) de un sistema de información.

El concepto de deuda técnica fue introducido por Ward Cunningham en el año 1992 y viene a decir que las taras en la calidad del software provocadas por unas malas prácticas en el desarrollo y/o la concepción del sistema de información (iniciar la codificación sin tener analizado convenientemente su alcance) provocan una situación de deuda (deuda técnica) que repercute en intereses (sobrecoste) no solo en el proceso de mantenimiento del sistema de información, sino también en la propia operativa de funcionamiento de la aplicación.

Esta deuda técnica y el coste que tiene asociado, desde mi punto de vista es algo incuestionable. Sí es discutible el cuánto, pero creo que a nadie se le escapa que un software desarrollado de manera deficiente tendrá más posibilidades de funcionar peor o tener más errores (esto supone también un coste) y también será mucho más complicado (y por tanto) más caro que mantener.

Si se tiene conciencia de la existencia de la deuda técnica se puede tomar dos decisiones, dejar el producto tal y como está y asumir ese pago de intereses o plantearse reducir la deuda, ya sea en bloque (un trabajo realizado a medida para ello) o introduciendo en los procesos de mantenimiento de los productos unos objetivos de evolución mínima en cada versión que se libere de la aplicación.

Por tanto, reducir la deuda técnica debe ser un objetivo en los distintos sistemas de información que una organización ha desarrollado, ¿se puede llegar a reducir a cero? Pues depende de dónde se pongan los límites para considerar que se ha eliminado la deuda técnica, ¿qué quiero decir con esto? Que sí se puede reducir la deuda técnica hasta tal punto de que los intereses que se paguen sean ridículos, pero que hay que equilibrar el esfuerzo que se requiere para conseguir este objetivo y los resultados reales que se obtienen con el mismo, es decir, hay que saber donde “atacar” para que con un esfuerzo razonable la deuda técnica de una aplicación no se note o no afecte en su funcionamiento y explotación.

Sonar establece que la deuda técnica es función de los siguientes aspectos: Duplicidades en el código, Complejidad Ciclomática, Cobertura del código por pruebas unitariarias, Comentarios en APIs públicas, Incumplimiento de las Reglas que se definan y los Ciclos que existan a nivel de paquete.

En resumen, la deuda técnica es un problema, sobre todo si es extensible a un buen número de sistemas de información de una organización, ya que provoca unos sobrecostes operativos y de mantenimiento. La deuda técnica reduce la eficiencia y por tanto es un concepto que cuando es conocido y sabiendo que se puede medir (independientemente de la fórmula que se decida utilizar) es conveniente empezar a madurar como establecer un plan de acción para reducir la deuda técnica y de esta forma reducir esos intereses que se están pagando por esos desarrollos, es importante señalar que hablo de plan de acción, no de solucionar el problema de la noche a la mañana, ya que estamos hablando de sistemas que están en producción y que deben ser mantenidos para que conserven su operativa diaria y para seguir adaptándose a los cambios demandados por los procesos de negocio que sostienen y por la necesidad de adaptarse cada vez más a las necesidades de los usuarios.

También hay que tener en cuenta que los presupuestos de desarrollo y mantenimiento de sistemas son limitados, por lo que sabiendo que una parte se dedica a mantener en funcionamiento los sistemas y otra para el desarrollo de nuevas necesidades en los mismos o nuevas aplicaciones, sólo va a quedar una porción del presupuesto para poderse invertir en reducir la deuda técnica, por lo que hay que tener un plan de acción que priorice sobre qué sistemas es conveniente plantearse primero la reducción de la deuda técnica.

Advertisement

• calidad del software
• desarrollo de software
• deuda técnica
• Gestión de Proyectos
• Sonar
• technical debt
• Ward Cunningham