La gestión de la deuda técnica

La deuda técnica es un concepto que se lleva manejando desde hace ya unos años. Muchos de vosotros habréis oido hablar de ello, y unos cuantos, como yo, lo habréis sufrido con dolor. Vamos a ver primero en qué consiste, y comentaré finalmente una iniciativa a nivel global para atender este grave problema que nos afecta en nuestra profesión.

¿Qué es la deuda técnica?

Qué curioso. Antes de explicar la deuda técnica, he querido contrastar mi definición con la de Wikipedia. Y qué decepción. Wikipedia explica, que la causa de la deuda técnica está en el ahorro de costes, que a su vez deriva en escasez de pruebas, y mala calidad de los productos implantados o incluso con errores conocidos.
Pues disiento. He visto proyectos bien sobrados de dinero, con abundancia de pruebas, y con resultados de calidad pésimos.
En mi opinión, la deuda técnica es la acumulación en el software de una o varias de las siguientes:

• Una o varias arquitecturas incongruentes entre sí o con las necesidades reales (o ausencia de arquitectura!).
• Inexistencia de estándares de programación, o existencia de varios estándares de desarrollo incongruentes entre sí.
• Falta de pruebas adecuadas a la solución requerida, de forma que posiblemente las pruebas se pasaron, pero el producto seguía adoleciendo de una baja calidad.
• Ineficacia en los programadores a la hora de realizar el código. Bien por usar soluciones inadecuadas o ineficades, no utilizar patrones cuando hubieran sido adecuados, o por el contrario, abusar de patronitis (ver mi entrada sobre esta enfermedad del software).
• En general, el uso y abuso de las distintas enfermedades del software que voy desgranando en este blog como son la ya comentada patronitis, cacheitis, etc.

Las consecuencias de todos estos problemas, se pueden ver tanto en proyectos faltos de presupuesto, como en complejos y grandes desarrollos bien dotados económicamente. Como ya he comentado en algún otro blog, los programadores tenemos la habilidad de echar siempre la culpa a los demás de todo, en lugar de hacer primero análisis, y después asumir la parte de culpa (mucha o poca) que podamos tener. Como decía las consecuencias son:

• Código espaguetti, o incluso código estructurado de formas tan diferentes entre sí, que parece una lucha de voluntades por parte del programador de impregnar cada uno, su forma de trabajar. El exceso de estándares es tan malo como su carencia.
• Ausencia de control de errores, o un uso que imposibilite obtener cualquier beneficio de dicha implantación.
• La documentación representa al software como un huevo a una castaña.
• No se ha hecho refactoring: el código se queda como está...o lo que es peor: los cambios se limitan a añadir más y más elementos, hasta que el código o es espaguetti, o dan ganas de atentar contra la vida de los diversos autores.
• Errores no subsanados, errores desconocidos (pruebas mal diseñadas).
• Control de versiones inexistente, de forma que no es posible saber qué versiones de unos módulos son compatibles con qué versiones del resto de módulos, o con la base de datos.
• Wikipedia nombra que una consecuencia sea que el producto no sea escalable. A ver, aquí encontramos una falacia: la escalabilidad tiene un coste. No todos los productos tienen una arquitectura de 7 capas con servicios distribuidos, escalables multiplataforma y bla bla bla...
• Wikipedia nombra otra consecuencia, que aunque cierta, hay que analizar: "Problemas al incorporar nuevas funcionalidades". Y es que un producto que cuesta cambiar, no tiene porqué significar que está mal hecho y que supone una deuda técnica. Todo depende del cambio. Una aplicación de gestión de personas, que se quiera adaptar a la gestión de vehículos...pues quizás el cambio no es trivial. ¿Acaso le vamos a echar la culpa al equipo de desarrollo anterior? 
• Finalmente, wikipedia indica otra consecuencia con la que discrepo: "Dificultades a la hora de actualizar la tecnología, o migrar a una nueva plataforma". Que un software admita un cambio de tecnología o de plataforma, es un requisito muy complejo. No es un requisito habitual, por otra parte. Por desgracia, no existe el software, en ningún patrón, framework o metodología que admita "cualquier tipo de mejora tecnológica o cambio de plataforma". Si esto existiese, se habría acabado la profesión de informática y sólo trabajarían unos pocos haciendo los escasos cambios necesarios. 

En general, y por simplificar, la deuda técnica es la degradación en la calidad del software y la dificultad en los cambios posteriores, debido a decisiones a corto plazo ineficientes (seguro que se os ocurre o leéis por ahí alguna otra frase más elaborada, pero bueno).

El término deuda técnica, se lo debemos a Ward Cunningham (igual os suena como el pionero del software en temas como la primera wiki, los patrones de diseño, o la programación extrema).

Lo realmente importante no es cuánto sepamos de la deuda técnica. Seguro que muchos de vosotros daréis una visión y descripción académica mucho más acertada y exacta que la mía. Lo que es importante, es que empecemos a ser conscientes de una vez de que el software no se construye y ya está. Alguien lo debe mantener, alguien debe hacerlo funcionar como realmente quería el cliente. Por desgracia, cuando pasa la época de las medallas (qué bonito es todo cuando se entrega el software y no se ha probado del todo por el cliente), llega la realidad de que el cliente no puede hacer todo lo que quería en su negocio, con las funcionalidades que al final se le han dado. Además, por desgracia, los que sufren el esfuerzo de "pulir" el software y terminarlo de arrancar, suelen ser personas totalmente ajenas a los que recibieron las medallas, víctores y premios por la entrega.

Iniciativa del SEI

El SEI (Software Engineering Institute), ha llevado a cabo recientemente un Workshop en el que se trataba la gestión de la deuda técnica desde el punto de vista de arquitectura del software. El evento tuvo lugar el 13 de marzo de 2012, pero tenéis información disponible en este link.

Además, el SEI está haciendo un esfuerzo en la investigación y estudio de este problema, que cada día se hace más palpable en el mundo del desarrollo de software.


Más información en:
http://www.sei.cmu.edu/newsitems/tech-debt.cfm
http://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica
http://en.wikipedia.org/wiki/Ward_Cunningham