Entender la deuda técnica

De Wikipedia: “La deuda técnica (también conocida como deuda de diseño o deuda de código) es “un concepto de la programación que refleja el trabajo de desarrollo adicional que surge cuando se utiliza código que es fácil de implementar a corto plazo en lugar de aplicar la mejor solución global”.

La deuda técnica puede compararse con la deuda monetaria. Si la deuda técnica no se salda, puede acumular ‘intereses’, lo que dificulta la implementación de cambios más adelante. La deuda técnica no abordada incrementa la entropía del software. La deuda técnica no es necesariamente algo malo, y en ocasiones (por ejemplo, como prueba de concepto) la deuda técnica es necesaria para hacer avanzar los proyectos. Por otro lado, algunos expertos sostienen que la metáfora de la “deuda técnica” tiende a minimizar su impacto, lo que se traduce en una priorización insuficiente del trabajo necesario para corregirla.”

El concepto de deuda técnica procede del mundo de la ingeniería de software, pero se aplica al mundo de la TI y la infraestructura empresarial en la misma medida. Al igual que en la ingeniería de software, diseñamos nuestros sistemas y nuestras redes, y tomar atajos en nuestros diseños —lo que incluye trabajar con diseños menos que ideales, incorporar hardware existente y otras malas prácticas de diseño— produce deuda técnica. Una de las formas más significativas de esta proviene de invertir en el “pasado” en lugar de en el “futuro” y, muy a menudo, se desencadena a través de la falacia del coste hundido (también conocida como echar dinero bueno tras dinero malo).

Es fácil ver cómo esto sucede en las empresas a diario. Se trazan nuevos planes para el futuro, pero antes de implementarlos se realizan inversiones para hacer que el diseño de un sistema antiguo siga funcionando, funcione mejor, se amplíe o lo que sea. Esta inversión se convierte luego, o bien en una pérdida financiera casi inmediata o, más a menudo, en un incentivo para no invertir en los diseños del futuro con tanta rapidez, tanta exhaustividad o, posiblemente, para no invertir en absoluto. La inversión en el pasado puede llegar a ser paralizante en los peores casos.

Esto ocurre de numerosas maneras y, por lo general, de forma no intencionada. A menudo se necesitan inversiones para mantener un sistema existente funcionando correctamente y, en condiciones normales, simplemente se realizarían. Pero en una situación en la que hay un cambio futuro que se necesita o que potencialmente está previsto, esta inversión puede resultar problemática. No obstante, en muchos casos, un mejor análisis de costes y una mejor planificación de prioridades pueden remediarlo.

En un ejemplo no técnico, imagine que posee un coche antiguo que le ha servido bien pero que va a ser retirado dentro de tres meses. Dentro de tres meses tiene previsto invertir en un coche nuevo porque el antiguo ya no resulta rentable debido a las continuas necesidades de mantenimiento, a la menor eficiencia, etcétera. Pero antes de que llegue su plan de tres meses para comprar un coche nuevo, el coche antiguo sufre una avería menor y ahora requiere una inversión considerable para mantenerlo en marcha. Poner dinero en el coche antiguo sería una nueva inversión en la deuda técnica. En lugar de gastar una gran cantidad de dinero para hacer que un coche antiguo funcione durante unos pocos meses, adelantar el calendario para comprar el nuevo es, obviamente, muchísimo más sensato desde el punto de vista financiero. Con los coches, vemos esto con facilidad (en la mayoría de los casos). Ahorramos dinero, potencialmente mucho, al comprar rápidamente un coche nuevo. Si invirtiéramos cuantiosamente en el antiguo, o bien perdemos esa inversión en unos pocos meses, o bien arriesgamos a modificar nuestra sólida planificación financiera para la compra de un coche nuevo que ya estaba decidida. Ambos casos son malos desde el punto de vista financiero.

La TI funciona del mismo modo. Gastar una gran suma de dinero para mantener un sistema de correo electrónico antiguo seis meses antes de una migración planificada a un sistema de correo electrónico alojado sería, con toda probabilidad, una gran insensatez. La inversión, o bien se pierde casi de inmediato cuando se da de baja el sistema antiguo, o bien socava nuestros buenos procesos de planificación y nos lleva a no migrar según lo previsto y a hacer un trabajo deficiente para nuestras empresas, porque permitimos que la deuda técnica dirigiera nuestra toma de decisiones en lugar de una planificación adecuada.

A menudo, una mala operación de gestión de prioridades o una autoridad inadecuada en quienes deciden las prioridades pueden ser el factor que provoca inversiones de emergencia en deuda técnica en lugar de inversiones rápidas orientadas al futuro. Esta es solo un área en la que las mejoras importantes pueden abordar los problemas, pero es una de las principales. Esto también puede mitigarse, en algunos casos, mediante una planificación de “qué pasaría si” para tener planes de inversión preparados que dependan de emergencias comunes o esperadas que puedan surgir, lo cual puede ser tan simple como las necesidades de ampliación de capacidad debidas al crecimiento que se producen antes de que entre en juego la planificación de sistemas.

Otro gran ejemplo de deuda técnica común es la ampliación de la capacidad de almacenamiento de los servidores. Este es un escenario que veo con cierta frecuencia y que ilustra bien la deuda técnica. Es habitual que una empresa compre servidores que carecen de gran capacidad de almacenamiento interno. Ya sea de inmediato o en algún momento posterior, se necesita más capacidad. Si esto sucede de inmediato, podemos ver que el servidor adquirido era una forma de deuda técnica por un diseño inadecuado y, evidentemente, representa un fallo en el proceso de planificación y compra.

Pero un ejemplo más común es la necesidad de ampliar el almacenamiento dos o tres años después de haber comprado un servidor. Las opciones de ampliación habituales incluyen añadir una cabina de almacenamiento externa para conectarla al servidor o modificar el servidor para que admita más almacenamiento local. Ambos enfoques tienden a ser grandes inversiones en un servidor ya antiguo, un servidor que fácilmente ha recorrido un cuarenta por ciento o más de su vida útil. En muchos casos, la misma inversión, o solo una ligeramente superior, en un servidor completamente nuevo puede dar como resultado hardware nuevo, CPU más rápidas, más RAM, el almacenamiento necesario diseñado y construido a propósito, un ciclo de vida de soporte alineado y renovado, una menor huella en el centro de datos, un menor consumo de energía, tecnologías y funciones más nuevas, mejores relaciones con el proveedor y mucho más, todo ello conservando el servidor original para reutilizarlo, retirarlo o revenderlo. Una vía gasta dinero apoyando el pasado; la otra, a menudo, puede gastar un dinero comparable en el futuro.

La deuda técnica es un factor paralizante para muchas empresas. Incrementa el coste de la TI, en ocasiones de forma significativa, y puede conducir a altos niveles de riesgo a causa de una falta de planificación y de que la mayor parte del gasto se base en emergencias.