Chapuza, Ñapa, llámalo como quieras menos solución

Hay muchas formas coloquiales de llamar a la deuda técnica que se acumula durante la ejecución de un proyecto, pero todas tienen en común el mismo efecto desastroso en los proyectos, uno de los peores males que existen en el mundo del desarrollo.

¿Que es la deuda técnica?

La Deuda Técnica se define como el coste implícito y futuro que se incurre al elegir una solución fácil o rápida ahora, en lugar de utilizar un enfoque más limpio y estructuralmente sólido que tomaría más tiempo.

Al igual que una deuda financiera, inicialmente se obtiene un beneficio rápido (se entrega la funcionalidad), pero si no se "paga" (refactorizando, mejorando o reestructurando el código o el diseño), se acumulan "intereses" en forma de: mayor tiempo necesario para realizar cambios futuros, aumento de errores (bugs), menor capacidad para escalar, dificultad para incorporar nuevas tecnologías o mejoras.

En resumen

Aplicar todo lo que indico aquí no es tarea sencilla, es mas, personalmente creo que es la parte mas complicada de la ejecución técnica de un proyecto. Pero os puedo asegurar que tanto si aplicas todo, como si solo consigues aplicar parte, obtendrás mejoras sustanciales. Solo debes tener en cuenta que su implementación debe partir desde la propia conceptualización del propio proyecto, vamos que cuando se determine la ejecución de una solución, se tengan en cuenta los puntos comentados..

La causa principal generalmente viene de la aplicación de arreglos rápidos sin verificación y análisis suficientes, esto es lo que viene a llamarse deuda técnica no intencional. Los efectos de acumular deuda técnica de manera descontrolada se manifiestan en la salud y sostenibilidad del proyecto en forma de baja productividad, aumento de costes, baja fiabilidad de la solución entregada, desmotivación del equipo. Todos estos síntomas se explican por si solos de la siguiente manera:

• Ralentización del Desarrollo: Cada nueva característica o corrección requiere más tiempo, ya que los desarrolladores deben navegar, entender y modificar un código complejo, mal estructurado, o con dependencias frágiles. Se pierde tiempo "desenredando" la chapuza anterior.

• Mayor Riesgo de Bugs: Al tocar una parte del código sin verificación, es más probable que se introduzcan nuevos fallos inesperados en otras áreas debido al alto acoplamiento (interdependencia) y a la falta de pruebas automatizadas que soporten la "ñapa".

• Coste de Mantenimiento Evolutivo: El coste total de propiedad (TCO) se dispara. Implementar un cambio que inicialmente se estimó en horas, puede tomar días o semanas solo por la dificultad de trabajar sobre una arquitectura deficiente.

• Obsolescencia Tecnológica: Se vuelve extremadamente difícil actualizar bibliotecas, frameworks o incluso migrar a nuevas tecnologías, forzando a la organización a trabajar con sistemas obsoletos y a menudo, inseguros.

• Vulnerabilidades Ocultas: Los atajos pueden pasar por alto buenas prácticas de seguridad o dejar puntos débiles en el sistema que son explotables o que provocan fallos inesperados en producción.

• Sistemas Frágiles: El sistema se vuelve inestable. Los fallos son crónicos y a menudo intermitentes, lo que genera desconfianza en los usuarios y en los propios desarrolladores.

• Desmotivación: Trabajar constantemente con código defectuoso, sin documentación y apagando "incendios" técnicos es frustrante. Esto puede llevar al desgaste ("burnout") de los desarrolladores y a una mayor rotación de personal clave, lo que ademas también dispara los costes de producción.

Algunos ejemplos

Estrategias para Evitarla

Ahora que sabemos lo que es y algunas de sus consecuencias, veremos algunas formas de evitar la deuda técnica. En términos generales, la clave está en adoptar una cultura de calidad continua y en integrar el "pago" de la deuda en el flujo de trabajo regular del proyecto, aunque todo depende de cada uno, yo divido el proceso en tres pasos: prevención, reparación, monitorización.

1. Incorporar la Calidad en el Proceso (Prevención)

   • Definir un "Definition of Done" (DoD) Estricto: Asegurarse de que una tarea no se considera "terminada" hasta que no cumpla con los estándares mínimos de calidad o lo que es lo mismo: que el código este revisado, las pruebas automatizadas estén pasadas, documentación actualizada y se cumplan los estándares de estilo.

   • Revisión de Código ("Code Review"): Es la herramienta más eficaz. Obliga a que al menos dos pares revisen cada cambio, identificando rápidamente "ñapas" o debilidades de diseño antes de que lleguen al código base.

   • Automatización de Pruebas (TDD/Unitarias/Integración): Un conjunto de pruebas robustas actúa como una red de seguridad. Permite al equipo realizar cambios con confianza, sabiendo que el sistema sigue funcionando correctamente.

2. Gestión Activa de la Deuda (Reparación)

   • Asignar tiempo a la refactorización: De forma regular, asignar tiempo a tareas de mantenimiento, mejora y refactorización.

   • Priorizar y Categorizar la Deuda: No toda la deuda es igual, por lo que tendremos que realizar un seguimiento de tareas, para registrar la deuda técnica. Teniendo esto controlado podremos priorizar la deuda en función de su impacto y cercanía al "corazón" del sistema o a las funcionalidades más utilizadas.

   • Metáfora de la Deuda: Siempre que se decida tomar un atajo intencional, debe hacerse de manera consciente y documentada. El equipo debe acordar cuándo y cómo se pagará esa deuda, de la misma manera que haríamos con un plan de amortización financiera.

3. Fomentar la Excelencia y la Responsabilidad (Monitorización)

   • Métricas de Calidad de Código: Utiliza herramientas de análisis estático que midan automáticamente la complejidad, la duplicación y la deuda técnica, haciendo visibles estos costes ocultos.

   • Responsabilidad del Código ("Code Ownership"): Fomentar que el equipo se "adueñe" y se sienta responsable de la calidad del código, Concienciando a tu equipo que para que nadie se limite a parchear un error para pasárselo a otro.