Seguro que todos hemos trabajado en algún proyecto en el que, ya sea por restricciones de tiempo, recursos o conocimientos, no se tomaban las decisiones correctas en todo momento. En el número de este mes de la revista Communications, Eric Allman escribe sobre esa situación, definida, en 1992, por Ward Cunningham como «deuda técnica«.

El desarrollo de un proyecto de ingeniería conlleva balancear constantemente tres variables: tiempo, funcionalidad y recursos. Se deben elegir dos pero jamás se podrán tener los tres. En el momento en que necesitemos los tres estaremos incurriendo en una deuda.

La deuda técnica puede aparecer de muchas formas diferentes: la escritura de un algoritmo más lento del necesario en producción pero que se implementa más rápidamente, el retraso del mantenimiento del hardware por recortes de presupuesto, posponer la escritura de la documentación hasta el final del desarrollo por escasez de personal que la redacte, omitir abstracción necesaria en la programación del sistema por no tener tiempo para comprender el código escrito por otros desarrolladores, etc.

El problema fundamental de la deuda técnica no es la deuda en sí, ya que en muchos momentos es aconsejable adquirir deuda, por ejemplo cuando se acerca el fin de vida del producto, o incluso imposible de evitar, como cuando se realiza un prototipo, sino no saber gestionarla. Pocos proyectos incluyen en su planificación el tiempo necesario para devolver esta deuda y acaban ahogados por los intereses de la misma.

El motivo principal de que la devolución de la deuda técnica no se planifique en los proyectos, y por lo tanto que no se devuelva, es el desconocimiento de los niveles superiores de gestión de las consecuencias que puede acarrear esta deuda sobre el proyecto.

La solución este problema, al igual que ocurre con la deuda financiera, es entender hasta el último detalle del compromiso al que estamos llegando y, desde los niveles más bajos, entender y hacer entender los riesgos. Una vez entendidos los riesgos hay muchas formas de devolver la deuda: desarrollos internos de mejora, releases de asentamiento y estabilización pactadas con el cliente, etc.

Conclusión: no es malo adquirir deuda técnica si todos los niveles dentro del proyecto entienden los riesgos que están asumiendo y se planifica de forma correcta como devolverla. Si no se entiende deuda técnica y no se planifica su devolución, se está condenando a los proyectos al fracaso por la asfixia de sus recursos, que consumirán más tiempo intentando pagar los intereses provocados por la deuda que en el avance del proyecto.