Deuda técnica
Neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software. Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase.
La deuda técnica suele materializarse en las siguientes formas:
- Documentación escasa, incompleta o inservible.
- Errores.
- Ausencia o deficiente control de versiones.
- Arquitectura no escalable.
- Rigidez para actualizar a nuevas tecnologías o plataformas.
El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero.
Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.
Y aunque las deudas técnicas se pueden clasificar en advertidas o inadvertidas, y en prudentes o imprudentes, atendiendo al reconocimiento o no de la deuda en el momento en que esta se da y a la realización o no de un análisis de costo frente a beneficios, y a pesar de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas:
- Errores conocidos y no solucionados.
- Mejoras en el código no implementadas.
- Insuficientes pruebas o pruebas de mala calidad.
- Documentación desactualizada, incompleta o inexistente.
El diario de deuda técnica Un diario de deuda técnica es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto.
Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes etiquetas:
- FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.
NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.
- TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.
- XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.
Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema.
Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone.