¿Qué es «deuda técnica», de dónde proviene y cómo se puede gobernar?
Si regresamos a los básicos de diseño de software, entonces podemos constatar que «deuda técnica» no es algo nuevo sino una idea de moda para referir lo mismo que autores como Meilir Page-Jones y Larry Constantine decían desde hace tres décadas sobre cohesión y acoplamiento y sobre el costo incremental inherente al nivel de desorden (entropía) en un sistema. Si, además, regresamos a los básicos de la teoría general de sistemas (pensamiento sistémico aplicado en cibernética), entonces podemos constatar que la entropía no se puede evitar, solo administrar.
La «deuda técnica», en general, es el nivel de desorden en un sistema. Proviene de los cabos suelos presentes desde la definición de un problema hasta los cabos sueltos en los detalles de implementación de una posible solución.
¿Cuáles son las implicaciones de intentar ignorar la «deuda técnica» o de no gobernarla adecuadamente?
Un efecto típico de «deuda técnica» no gobernada es, entre otros, la decisión de descontinuar un sistema pues su costo de evolución se hace insostenible o porque su capacidad para ajustarse a nuevos requerimientos es demasiado pobre y costosa. Para un negocio basado en software ese efecto puede ser devastador. Por ejemplo, para la compañía Netscape Communications tal efecto contribuyó al declive de su producto comercial Netscape Navigator y, a fin de cuentas, a su bancarrota.
¿Cómo gobernar la «deuda técnica» en un sistema?
No dejar cabos sueltos desde la definición de un problema hasta la implementación de una posible solución. Uno de los cabos sueltos más frecuentemente ignorados es la administración de dependencias en un diseño de software; es decir, abandonar tal diseño a la tendencia natural hacia el espagueti (entropía). El gobierno de una «deuda técnica» incluye aplicar pagos o abonos constantes: esfuerzo explícito para administrar las dependencias en cada cambio al diseño en todos los niveles de abstracción involucrados en dicho cambio. Si no se abona a la deuda, ésta tan sólo crecerá.
Por supuesto, hacer un cambio a un diseño demanda contar con pruebas manuales y automatizadas pertinentes que ayuden a identificar el nivel de propagación de las consecuencias de dicho cambio.
En este contexto sugiero evaluar la siguiente aportación que recién publiqué. Se trata de un componente para administrar dependencias como medio para gobernar la deuda técnica en diseños de software que utilicen .NET Framework:
http://www.nuget.org/packages/TypeClassMapper/
Está basado en una idea básica de extensibilidad existente en Windows desde C++/COM/COM+ y también en .NET Framework. Dicho mecanismo sirve para concretar un patrón de diseño llamado Inversión de Dependencias o Inversión de control (Dependency Inversion Principle, DIP). El cual permite desacoplar por completo una interfaz de sus posibles implementaciones y ser enlazadas por separado en runtime por medio de configuración.
En años recientes muchos han empaquetado dicho principio en varias librerías. Algunas han cobrado alguna popularidad. Nunca he usado dichas librerías pues suelen agregar mucha funcionalidad que no necesito y que sólo las hace innecesariamente grandes; además de aumentar la complejidad del software que las usa.
Su documentación y ejemplos de uso están en el Project Site correspondiente.
Toda valoración crítica, reporte de defectos, solicitudes de funcionalidad, o de cambios, y contribuciones abiertas son bienvenidas.
