Deuda técnica: entre lo urgente y lo importante

La calidad de los sistemas software comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento. 

- ​ptima Ley de Lehman de la evolución del software.

Posponer mantenimiento y actualización por parches rápidos y pases a producción para ayer, es en esencia deuda técnica. Son todas las tareas por hacer para que las aplicaciones sean viables a través del tiempo, que se acumulan en la cola de pendientes. Publicar ahora, correcciones después.

La causas varían, áreas de negocio enfocadas en producir funcionalidades nuevas dando espacio solo para parchar más que corregir, programadores novatos poco preocupados por la visión general del sistema, o la falta de un plan para el mantenimiento del sitio. Uno de los síntomas es el abuso de las soluciones quick and dirty, así estas aplicaciones crecen sacrificando calidad. 

La resultado lógico es un sistema defectuoso que cada día consume más tiempo en estar productivo, con una consecuencia adicional: la renuncia de programadores, si su razón de ser es escribir buenos programas, que la gerencia no provea espacio por resolver la deuda técnica niega su razón de ser.

La deuda técnica no tendrá mayor importancia para la áreas de negocio si esta no es explicada en su idioma: dinero. Las consecuencias calculadas en horas/hombre en vano, transacciones fallidas o recurso malgastados permiten a la administración una visión clara sobre las perdidas y permitirán priorizar adecuadamente la eliminación de la deuda.

¿Como definir entonces entre lo urgente y lo importante? Acumular bugs no es rentable, ese tiene que ser el mensaje.