Una de las dificultades del software es su inmaterialidad. Es difícil observarlo, apreciarlo y medirlo. Entre 1964 y 1972, Lehman y Belady estudiaron la evolución de programas complejos en IBM y formularon algunas leyes empíricas, como la del cambio constante (el sistema debe ser adaptado continuamente o perder vigencia) y la de la complejidad creciente (el sistema se hace más complejo a medida que evoluciona, salvo que se intervenga deliberadamente para mejorar su estructura).
En 1992, Ward Cunningham enunció la metáfora de la ‘deuda técnica’: decidir entre obtener beneficios por liberar rápidamente software inmaduro y pobremente estructurado, contra los costos de lidiar con darle mantenimiento en plazos medianos y largos. Es frecuente desarrollar sin dar mayor consideración a la calidad interna (estructural) del software y a la proyección de las dificultades que esto pueda provocar en su evolución futura, por cambios, extensiones, adaptaciones e integraciones que serían requeridos para mantenerlo vigente.
La metáfora sugiere pensar en términos económicos y comparar los costos y beneficios de una salida rápida contra el “interés” y la “amortización” que comprenden el reparar y mejorar software con características pobres, que podrían afectar su mantenibilidad y utilidad. Salir temprano al mercado con un producto funcional puede ser beneficioso, pero la metáfora llama a imaginar los costos de mejorar un producto que va a evolucionar como consecuencia de su propio éxito.
Postergar las mejoras para corregir los problemas estructurales, u otros (como carencias de documentación), es como incurrir en endeudamientos en préstamos o tarjetas de crédito a los que uno no podrá hacerles frente. La deuda técnica no manejada puede llevar a empresas a la quiebra, como ocurrió con Ashton-Tate –creadora de la familia de productos dBase en los ochentas–.
Artículo publicado en el periódico El Financiero
