Una organización genera una deuda técnica cuando da prioridad a un enfoque de desarrollo rápido y de bajo coste por encima del ciclo de vida de desarrollo convencional. Aunque puede ser gratificante a corto plazo, no cabe duda de que a largo plazo no es lo mejor para la organización. Además, las organizaciones con deuda técnica acumulada solo se plantean abordarla periódicamente y prestan poca atención a menos que la solución de las incidencias se convierta en una prioridad. Aunque el sector no cuenta con una métrica acordada para calificar la deuda tecnológica de un sistema, con el tiempo empiezan a aparecer ciertos indicios de fiabilidad y velocidad, lo que acaba repercutiendo en los costes de funcionamiento.
¿Por qué se llama deuda y no riesgo/incidencia?
La “deuda” en la que se incurre como parte de la deuda técnica suele ser la compensación de tiempo por hacer algo bien frente al camino más corto hacia el producto mínimo viable (MVP) a lo largo del ciclo de vida del producto. La deuda técnica acumulada a lo largo del tiempo infla los presupuestos de “ejecución y error”, además de afectar a la longevidad de las plataformas que deben recodificarse para ser compatibles con las nuevas tecnologías. Algunos líderes del sector creen que esta deuda es como un riesgo, pero cuando este riesgo se materializa, se convierte en un impacto, por lo que es esencial abordarlo cuanto antes.
Cinco mitos sobre la deuda técnica
Estas son las cinco ideas preconcebidas más comunes sobre la deuda técnica que dificultan una actuación rápida:
- La deuda técnica tiene que ver con la calidad del código y las dependencias.
Aunque la calidad del código influye en el mantenimiento del producto, aspectos como la arquitectura, el diseño y las opciones de infraestructura también afectan significativamente al tiempo de comercialización.
- Los últimos marcos/tecnologías ayudan a las organizaciones a no contraer ninguna deuda técnica.
Las organizaciones a menudo asumen que al ejecutar la última versión del marco de trabajo más cool o la transición de monolito a microservicios, ya no tienen ninguna deuda técnica, pero la realidad es muy diferente. Depende mucho de la infraestructura técnica de la empresa. En la mayoría de las organizaciones, existe una importante interdependencia entre sistemas que agrava el problema de la deuda técnica y afecta la fiabilidad de las plataformas.
- La deuda técnica es mala.
Si se utiliza correctamente, la deuda técnica puede acelerar el ciclo de los productos. Sin embargo, lo importante es abordar la deuda técnica tan pronto como sea posible después de las etapas de producto mínimo viable para garantizar un mejor retorno de la inversión. La deuda acumulada inicialmente puede compensarse si se gana en velocidad para corregir y tomar decisiones de diseño prudentes.
- La deuda técnica solo afecta a los ingenieros de software.
Las organizaciones suelen suponer que el impacto de la deuda técnica se limita a la comunidad de ingenieros de software y que ellos pueden crear soluciones para resolver el problema. Por ejemplo, cuando los neumáticos de un camión empiezan a desgastarse, otras piezas como los accesorios y los muelles también empiezan a degradarse en paralelo. Del mismo modo, a medida que la deuda técnica empieza a afectar a los equipos técnicos, el cansancio también se apodera de las organizaciones de asistencia técnica y de los propietarios de los productos y aumentan los problemas generales relacionados con la resiliencia.
- La adopción de DevOps de alto nivel y la visión de futuro evitan que las organizaciones contraigan deuda tecnológica.
En muchas situaciones, la adopción de DevOps con problemas de dependencia y diseño contrarrestan las ventajas de la velocidad debido al software “hinchado”, lo que acelera los síntomas de la deuda técnica y afecta visiblemente al producto.
En pocas palabras, vale la pena que las organizaciones acepten que los sistemas en cuestión pueden tener deuda técnica y tomen medidas para evitar un posible aumento.