Cómo medir la deuda técnica
En la vida suele haber más de una forma de alcanzar un objetivo. El camino que elige una persona puede ser completamente diferente del recorrido o método que otra usa para llegar al mismo punto.
Este concepto también se aplica al desarrollo de software.
Sin embargo, al crear software puedes tomar distintas rutas para llegar al mismo lugar, y aun así una puede ser mejor que otra. Entonces, ¿cómo encuentras la verdadera «mejor manera» de construir un sistema de software efectivo? Es un gran dilema.
Cuando un desarrollador o un equipo adopta un enfoque equivocado de ingeniería de software, incurre en deuda técnica, lo sepa o no.
En este artículo explicamos el concepto de deuda técnica y cómo un responsable de producto puede medirla, gestionarla y reducirla.
¿Qué es la deuda técnica?
Supongamos que tus equipos eligen constantemente un método de desarrollo más sencillo e intuitivo en lugar de opciones avanzadas, pero más laboriosas. Completan las tareas con facilidad, pero el proceso introduce lentamente fallas en el código y la arquitectura. Con cada decisión basada en esa base defectuosa, el equipo acumula, poco a poco, una deuda de software, es decir, deuda técnica.
Es natural pensar que cualquiera querría construir un sistema de software de la forma correcta. Pero la forma correcta suele ser la más difícil. Al comparar la complejidad del código de algoritmos de fuerza bruta, normalmente sencillos e intuitivos, con versiones avanzadas menos intuitivas, es mucho más fácil elegir el camino que requiere un razonamiento más simple.
Además, considera todas las presiones externas para entregar algo atractivo rápidamente. No sorprende que un equipo de ingeniería elija la ruta más rápida del punto A al B sin considerar el costo de esos atajos.
El problema es que, para ser un responsable de producto exitoso, debes hacer las cosas bien desde el principio. De lo contrario, es muy probable que tengas que volver atrás en algún momento y compensar la falta de esfuerzo o de atención al detalle.
El origen del problema
La deuda técnica puede ser deliberada o involuntaria. La mayoría de los equipos de ingeniería de software tiene cierta conciencia de que se acumula a medida que avanza.
Como ocurre con la deuda financiera, la deuda técnica genera intereses. Cuanto más tiempo pases sin corregirla, peor será el problema. ¿Por qué? Por la forma en que funciona la programación, a menudo debes crear más código defectuoso para corregir el original. Con el tiempo, necesitarás aún más código mal escrito para intentar gestionar el desorden creciente.
La deuda técnica accidental puede surgir de problemas latentes anteriores al equipo actual. Un ejemplo es el software desactualizado. A medida que los estándares suben y los costos de mantenimiento aumentan, es fácil quedarse atrás sin darse cuenta.
Los costos de la deuda técnica
Una vez que empiezas a descuidar el código, es difícil dejar de hacerlo. Al añadir funcionalidades más adelante, los desarrolladores incorporan más código defectuoso. Con el tiempo, se abandonan los compromisos iniciales de crear algo limpio y efectivo y se reducen los estándares. La realidad es que mantener código defectuoso se vuelve más complicado, por lo que solo empeoras las cosas para ti y para tu equipo.
La ruta del «atajo» hacia la meta tiene sus propias consecuencias. Los distintos tipos de deuda técnica pueden causar problemas de productividad, complejidad del código, cobertura de pruebas y cantidad de líneas. Además, debes considerar los costos de que tus equipos pierdan tiempo sorteando problemas del sistema o lo renueven por completo cuando la deuda técnica sea demasiado difícil de gestionar.
Medir la deuda técnica: el índice de deuda técnica
La mejor manera de evitar estos problemas y costos en el desarrollo de software es medir la deuda técnica y luego encontrar soluciones para gestionarla.
Primero, hay muchas variables que debes considerar al calcularla: complejidad ciclomática, líneas de código, profundidad de herencia, profundidad de anidamiento, acoplamientos aferentes y eferentes, y muchas más.
Como regla general, la solución más sencilla es expresar el problema como un índice. El índice de deuda técnica mide la diferencia entre el costo de corregir el software y el costo de desarrollarlo.
Índice de deuda técnica = (costo de corrección dividido entre costo de desarrollo) x 100
Lo ideal es tener un índice de deuda técnica del 5% o menos. Si es mayor, refleja software de baja calidad.
Apliquemos este análisis a un caso de negocio. Supongamos que quieres convertir el costo de corrección (RC) en una función de la métrica de calidad que tu equipo considere más pertinente según las reglas para resolver problemas de código. Puedes expresarlo como una función de la complejidad ciclomática, que describiría cuánto se tarda en corregir problemas de una función de código. El RC se vuelve directamente proporcional a la complejidad de esa función. Una vez que lo determinas, puedes calcular cuánto tiempo llevará corregir todo el problema.
Puedes aplicar este mismo concepto a otras métricas de calidad del código y medir y gestionar la deuda técnica de otras maneras.
Reducir y gestionar la deuda técnica
La mejor manera de reducir la deuda técnica es gestionarla regularmente y no dejarla de lado. Es fácil ignorarla hasta llegar a la meta, pero cuanto más la evites, más lejos empujará la verdadera línea de llegada.
Mientras construyes tu software, considera lograr una cobertura de pruebas regular mediante automatización para reducir la acumulación de deuda técnica. Volver a revisar esta fórmula expresada como índice durante el desarrollo te ahorrará horas de trabajo y mucho dinero más adelante, a cambio de un esfuerzo mucho menor ahora. En ingeniería de software, siempre vale la pena hacer las cosas correctamente.