Managing Technical Debt

El concepto de deuda técnica no es nuevo, ha existido desde hace mucho tiempo con otros nombres (p.e. coste de la no-calidad, entre otros). Lo interesante de éste es que, según mi experiencia, capta mucho mejor la atención de los directores, jefes y otras figuras no técnicas que toman decisiones sobre los proyectos de software.

El concepto consiste a las eventuales consecuencias de usar arquitecturas deficientes (decisiones técnicamente incorrectas) o seguir malas prácticas de desarrollo de software ("trabajar mal"), usualmente materializadas en trabajo sumergido en un momento dado pero que tarde o temprano tendrá que afrontarse (pagarse) para poder acabar el proyecto. El fin del proyecto no significa el fin de la deuda, pues el mantenimiento de cualquier producto con deuda técnica se encarecerá notablemente, además de dejar una mala imagen del equipo o empresa que lo desarrolló.

Por un lado, las consecuencias más típicas de tener un proyecto con deuda técnica son:

• Retrasos en las entregas (la planificación deja de cumplirse en cuanto emerge la deuda técnica).
• Productos con mala calidad para el usuario (visible) y para aquellos que lo mantienen (invisible).
• Mayor coste de mantenimiento y coste total de la propiedad (TCO).
• Desmoralización del equipo y excesiva rotación del personal.

Por otro lado, los motivos más habituales de la deuda técnica suelen ser:

• Mala planificación o presiones por avanzar en el proyecto sin atender a criterios técnicos.
• Falta de metodología o comunicación en el equipo (o entre equipos).
• Malas prácticas como el "hardcoding" o los componentes altamente cohesionados.
• Falta de pruebas unitarias y pruebas automáticas de regresión.
• Falta de documentación
• Muchos otros

También hay que tener en cuenta que la deuda técnica puede tener otras características:

• consciente: p.e. no hacer pruebas unitarias para poder hacer una demo interna a tiempo (pero se harán inmediatamente después).
• inconsciente: p.e. no hacer pruebas unitarias porque retrasa el proyecto (hasta que aparezcan los errores que serán probablemente más caros de solucionar).
• a corto plazo: p.e. no documentar para llegar a un hito urgente (reunión con otro equipo), pero liquidar la deuda en breve.
• a largo plazo: p.e. desarrollar la capa de persistencia para Oracle 11g porque no se espera usar otra BD en producción.

El tema da para mucho y mejor no eternizarse. Podéis consultar una presentación del clásico Steve McConell.

Espero poder presentar sobre este tema en la Barcelona Developers Conference 2013. Si os parece interesante... ¡votadme por favor! :-)