EscucharLas metáforas nos ayudan a pensar en problemas particulares. Ward Cunningham acuñó en 1992 la metáfora de la deuda técnica para contribuir al pensamiento de decisiones relacionadas con la construcción de software.
Ward afirma que es una muy buena idea obtener un préstamo para aprender —por ejemplo, cómo será utilizada una pieza de software novedosa—; es el equivalente a poner en uso un programa informático que no está listo, porque vamos a aprender del usuario.
La deuda se pagará cuando el software se rediseñe y construya con el nuevo conocimiento adquirido. El gran problema aparece cuando la deuda técnica no se paga. Al igual que una deuda financiera, los intereses siguen creciendo al punto que consumen todos los ingresos.
Cada vez que se pone una pieza de software en producción con defectos —conocidos o no—, se adquiere una deuda técnica. El precio de corregir los defectos en el futuro es el principal de la deuda y el costo extra de mantener el programa hasta que se corrijan los defectos es el interés.
El tamaño de la deuda técnica tiende a ser proporcional al tamaño de la organización y a la edad de sus sistemas. Organizaciones muy grandes con sistemas muy antiguos suelen tener una deuda técnica muy elevada.
Debe ser mensurable. La utilidad de la metáfora sería muy limitada si no es medible. Recientemente, en la conferencia mensual del Club de Investigación Tecnológica, tuvimos la suerte de contar con la participación del Dr. Bill Curtis, director ejecutivo del Consorcio para la Calidad de Software de TI (Ciscq), cuya conferencia se tituló «Medición y administración de deuda técnica».
Gracias a la utilización de software especializado en analizar el código fuente de las aplicaciones, es posible detectar más de 1.200 faltas de codificación y arquitectura, que afectan el rendimiento, robustez, seguridad y capacidad de transferencia y modificación del software.
Con datos históricos del mantenimiento de las aplicaciones se obtienen estimaciones del tiempo requerido para corregir cada falta (las arquitectónicas son mucho más difíciles). Los registros financieros aportan datos del costo total real por hora de los desarrolladores.
Con todos esos datos en una base de código de más de 320 millones de líneas de código (745 aplicaciones de 160 organizaciones en 14 países) llegaron al estimado conservador de $3,6 por cada línea de código. Ese es el principal de la deuda técnica. Es interesante notar que encontraron una falta por cada 6 líneas de código.
En nuestro medio es muy imitado el uso de herramientas de análisis estático de software, pero, sin dichas herramientas, la medición y la administración de la deuda técnica es muy difícil, por no decir imposible. La mayoría de las organizaciones ni siquiera saben cuántas líneas de código tienen ni mantienen bien organizados sus repositorios de código.
Deuda costarricense. Las grandes instituciones públicas costarricenses deben tener decenas de millones de líneas de programación, lo cual sugiere deudas cercanas a los $100 millones cada una. La del país ronda los miles de millones de dólares.
Si pensamos que en Costa Rica unas 25.000 personas desarrollan software y cada una escribe, muy conservadoramente, 10 líneas (limpias y netas) diarias, la base de software crece 50 millones de líneas anuales. Eso nos llevaría a pensar que la deuda técnica se incrementa en $180 millones al año para todo el país.
Pero ese es solo el principal, ¿y los intereses? El interés de la deuda es más difícil de calcular. Es el tiempo y esfuerzo extras cada vez que hay que hacer un cambio a la función de una aplicación.
Resulta que el 70 % de las faltas que generan deuda se dan en costos de TI (transferencia, modificación) y únicamente el 30 % es producto del riesgo comercial (robustez, rendimiento, seguridad). Esto sugiere que, conforme se le da mantenimiento a una aplicación, crece la deuda técnica y decrece la productividad del personal dedicado, porque cada vez es más difícil hacer cambios a una aplicación más compleja.
La solución es reducir el principal, amortizar la deuda, esto es, asignar recursos a la corrección de defectos conocidos, que por diversos motivos fueron pospuestos. También es urgente conocer los defectos no conocidos, para eso hay que utilizar herramientas que analicen el código fuente de las aplicaciones.
Sustitución. No hay duda de que el análisis de algunas aplicaciones muy viejas sugerirá reemplazarlas en lugar de corregirlas, porque, si bien es cierto que el software ni se rompe ni se gasta, con el tiempo es capaz de volverse tan complejo que se torna inmanejable, y es mejor retirarlo y sustituirlo.
Más necesario quizás sea incluir la variable calidad del software en el análisis de la decisión típica entre construir o comprar (ahora alquilar) programas informáticos.
Suponer, sin medir, que la calidad del software desarrollado internamente es similar al del contratado o adquirido, deriva en decisiones totalmente sesgadas, que en muchas ocasiones terminan por ser desastrosas.
El análisis del código fuente nos brinda una muy buena estimación de la calidad del software y la posibilidad de establecer estándares, debajo de los cuales no se pone ningún programa en producción.
Además, conocer la calidad de lo que producimos o compramos contribuye a plantear mejoras en los procesos de desarrollo, adquisición y mantenimiento del software.
Es corriente escuchar quejas de jerarcas de empresas e instituciones por el elevado costo de los programas informáticos, pero no tiene mucho sentido dejar de medir la calidad, pues representa una porción muy cuantiosa del costo. El software deficiente es caro hoy y lo será, aún más, en el futuro.
El autor es ingeniero, presidente del Club de Investigación Tecnológica y organizador del TEDxPuraVida.
