La deuda técnica en el desarrollo de software

Hoy he aprendido un nuevo concepto que me ha llamado mucho la atención, y que a lo largo de mi trabajo como programador software lo he sufrido y mucho. Nunca le había conocido un nombre hasta hoy: la deuda técnica (technical debt en su origen inglés), pero siempre he sido consciente de su existencia y de sus consecuencias.

Atajo

Me voy a centrar en la utilidad de la deuda técnica INTENCIONADA, es decir aquella deuda que dejamos pendiente de saldar con conocimiento de causa y sus consecuencias. Esto es diferente de la deuda técnica no intencionada debida los defectos introducidos en el software, este caso ocurre por muchos motivos y es más complicado de tratar y documentar.

¿En qué consiste la deuda técnica intencionada?

Si has trabajado en proyectos de desarrollo de software con una pobre planificación, o bien con una fecha demasiado ajustada para cumplirla, o quizás por otros motivos, es fácil que te haya llevado a optar por una solución provisional menos óptima, por ser más simple y rápida.

¡Ojo!, una deuda técnica intencionada no es sinónimo de una chapuza o la típica ñapa, esta deuda es un compromiso para satisfacer unos requisitos y cumplir con una entrega pactada. Este compromiso permite tomar un camino más rápido con la promesa de, mediante un refactoring o reescritura del código, resolverlo posteriormente de forma más correcta, idealmente en un futuro más bien cercano.

Un ejemplo típico es hacer un código más sencillo con una optimización muy básica que soportará un volumen de accesos bajo. La deuda técnica pendiente será refactorizar cambiando el código para implementar colas, cachés o una optimización costosa de la base de datos.

Otro ejemplo es relajar la seguridad de la aplicación para una demo a un cliente, aquí es más evidente que no pagar la deuda podría ser muy doloroso en el paso a producción.

A nivel de diseño también podrías adquirir una deuda técnica intencionada, pero estas son más complicadas y poco recomendables salvo que esté bien justificado y controlado. Este tipo de deuda en diseño ha de documentarse muy bien hacia abajo para tener en cuenta este detalle en la codificación. El posterior pago de la deuda probablemente llevará mucho más esfuerzo.

Deuda técnica

Documenta tus deudas y gestiónalas

Es importante que todas estas deudas que vamos dejando estén documentadas para no olvidar por qué existen. En mi caso solía documentar lo más importante mediante la decoración de la pantalla con posits. Pero después de acumular muchas deudas tenía la sensación de que era mejor rehacerlo todo según aumentaba su volumen, y lo que era peor, si no documentabas bien, olvidabas el motivo de la deuda.

Así que toma conciencia que existen las deudas técnicas y utilizarlas en mi opinión no es malo, te permite desarrollar más rápido. A cambio has de tener en cuenta que en algún momento has de incorporar el pago de esas deudas al flujo de trabajo, y mejor cuanto antes, que los intereses luego pueden ser muy altos o directamente inasumibles.

Pero si no incluyes el pago de tus deudas técnicas en tu metodología de trabajo, y en un tiempo razonable, entonces tu código no será óptimo, dejará de cumplir los requisitos para los que se escribió y finalmente quedarán pegotes como:

/* TODO: Eliminar este mega-bucle O(n3) */

y posiblemente el mantenimiento del código spagetti:

Spagetti code