Hoy (2014) he aprendido una nueva definición que me ha llamado la atención por el nombre, y que a lo largo de mi trabajo como programador he tenido que lidiar con ello. Nunca le había conocido un nombre hasta hoy: deuda técnica (technical debt en su origen inglés), aunque de alguna manera siempre he sido consciente de su existencia y de sus consecuencias.
Se trata a la deuda como algo malo a evitar, pero me voy a centrar en la utilidad de la deuda intencionada que dejamos pendiente de saldar con conocimiento de causa y sus posibles consecuencias.
¿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 más básicos y cumplir con una demo o una primera entrega preliminar. 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.
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 podría ser refactorizar cambiando la arquitectura o el código para implementar colas, caches o una optimización 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 al 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 o rehacerlo casi todo, pero la ventaja de que sabré mucho más de lo que pretendo solucionar y lo que no debo implementar.
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 listas de pendientes, 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 es peor, si no documentas olvidas 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 y probar 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.
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 reales para los que se escribió y finalmente quedarán pegotes para la posteridad.
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42