Lo bueno (al menos lo vamos a intentar) se hace esperar, el mini-proyecto de la trilogía macedonia abre su andadura con el post de enfoque más técnico y por eso voy a intentar hacer divulgación y explicar de forma sencilla el concepto de “deuda técnica”.
Supe del término por primera vez este año en una reunión informal entre gente de Sistemas y Desarrollo y pese a su importancia creo que no se le presta la atención suficiente por parte de algunos gestores de proyectos y menos aún por los responsables comerciales, lo que ocasiona no pocos problemas, ya no solo a la hora de llevar a buen puerto un proyecto, sino de su mantenimiento a lo largo del ciclo de vida del producto.
La persona que acuño el término fue Ward Cunningham, y lo hizo para describir aquel código que se escribe de forma rápida, basado en obtener posibles beneficios a corto plazo, sin tener en cuenta los costes adicionales (intereses) que va a suponer en forma de mantenimiento extra por su baja calidad a lo largo del tiempo.
Muchos tratan de hacer símiles con la idea de la deuda financiera, y aunque creo que conviene mantener ambos conceptos por separado, es una buena aproximación para que le gente como yo, de formación no técnica, lo pueda entender.
Leyendo sobre el tema, me ha parecido muy interesante descubrir la raíz del concepto, ya que no es algo nuevo, sino un problema con más de 40 años de historia y que se le conoce como “crisis del software”. Algo que la OTAN (sí, la Organización del Tratado del Atlántico Norte, aquella de: “OTAN, de entrada no”) identificó en 1968 y que atañe a una serie de problemas que son comunes a la mayoría de los proyectos de software:
- Finalización fuera de plazo
- Costes por encima de lo previsto
- Baja calidad del software
- Software que no cumple con los requisitos iniciales
- Código inmantenible que dificulta la gestión y evolución del proyecto.
Es ese último punto de la “crisis del software” el que entra en relación directa con el concepto que estamos analizando. Y es que puede haber un punto, en el que el coste del pago de los intereses de la “deuda técnica” acabe con la rentabilidad del proyecto e inicie su inexorable camino a la bancarrota. Una bancarrota que supondría el esfuerzo de tener que empezar a reescribir el código del proyecto desde cero, con las nefastas consecuencias que ocasionaría a todos los implicados en el proyecto.
Entonces, ¿es siempre la “deuda técnica” un riesgo a evitar en nuestros proyectos? Pues depende, al igual que puede ser imprescindible para una empresa textil ampliar la línea de crédito financiero para abordar el lanzamiento de una nueva línea de ropa masculina, es probable que en alguna ocasión nos veamos en la tesitura detener que decidir si debemos asumir el coste que supone la “deuda técnica” en alguno de nuestros proyectos de software.
Pero no vamos a entrar más en detalle por ahora, ya que dentro de poco lo haremos en el capítulo II de la trilogía macedonia, donde veremos, desde la óptica de la gestión de proyectos, los efectos de la “deuda técnica” en los mismos y cómo gestionar los riesgos que puede implicar.
mimacedonia-blog posted this