En términos generales, la deuda técnica se refiere al “costo” de mantener y actualizar el software debido a una planificación insuficiente, falta de diseño o a la implementación de “atajos” durante el proceso de desarrollo. Esto da como resultado un backlog lleno de elementos que representan las mejoras necesarias y que a su vez se puede traducir en costos (ya sea en horas hombre, pérdida de productividad u otros tipos de monetización).
El término “atajo” se usa aquí para describir código o implementaciones de baja calidad (es decir, algoritmos incorrectos, integraciones incorrectas, configuración incorrecta u otras decisiones técnicas deficientes), y que pueden conducir a dificultades para realizar cambios futuros, causar ineficiencias e incluso producir defectos a largo plazo.
Tipos de deuda técnica
La deuda técnica se puede agrupar en 5 grandes categorías:
- Deuda arquitectónica
- Deuda de código
- Deuda de procesos
- Deuda de decisiones
- Deuda de seguridad
No es raro que estas categorías se amplíen aún más o incluso se cambien dependiendo de las características del proyecto de software, por ejemplo, para ajustarse al tipo de aplicación, su criticidad dentro de una industria en particular, las plataformas dentro del alcance, el proceso de desarrollo utilizado e incluso los roles involucrados.
Las siguientes descripciones brindan una mejor comprensión de cada tipo de deuda técnica con ejemplos de los tipos de problemas de software de calidad que pueden estar relacionados con cada uno.
Deuda arquitectónica
Se trata de inconsistencias en el diseño y la arquitectura del software que conducen a problemas de escalabilidad y mantenibilidad, así como bajo o nulo cumplimiento de otros requisitos no funcionales. Este tipo de deuda puede por ejemplo generar defectos a nivel del sistema, cuellos de botella en el rendimiento o problemas de escalabilidad e incompatibilidad que pueden llevar mucho tiempo en ser solucionados.
Deuda de código
Se refiere a la mala calidad del código, falta de documentación y falta de pruebas unitarias que conducen a dificultades para comprender y mantener/mejorar el código del software. La deuda de código puede dar lugar a defectos de implementación, bajo rendimiento, funcionalidad frágil, incapacidad para realizar actualizaciones en dependencias de software (como bibliotecas) o actualizaciones de hardware subyacentes, así como crear vulnerabilidades de seguridad.
Deuda de proceso
Cuando los procesos de desarrollo son ineficientes por ejemplo al generar definiciones inadecuadas de la funcionalidad requerida, la falta de revisiones de código, pruebas ineficaces o insuficientes, se puede traducir en requisitos no implementados, esfuerzos de desarrollo duplicados o desperdiciados y falta de calidad general en el producto de software (por ejemplo, introducción de defectos, así como vulnerabilidades de seguridad).
Deuda de decisión
La implementación de soluciones rápidas en lugar de soluciones a largo plazo, investigación o análisis insuficientes de un requisito o un defecto pueden conducir a problemas de mantenimiento y soporte a largo plazo relacionados con malas elecciones de diseño o una gestión de riesgos inadecuada.
Deuda de seguridad
El descuido de las consideraciones de seguridad, como la falta de implementación de protocolos adecuados, bibliotecas actualizadas, configuraciones inadecuadas o reinventar la rueda en lugar de usar soluciones probadas puede derivar a una mayor superficie de ataque para ataques cibernéticos (por ejemplo, debido a la falta de controles adecuados de autenticación y autorización o vulnerabilidades sin parches).
Pero eso no es todo
Como se puede apreciar, la identificación adecuada y oportuna de la deuda técnica podría ser la diferencia entre un proyecto exitoso o uno condenado al fracaso, pero capturar toda esta deuda de diferentes tipos puede parecer desafiante y engorroso incluso para un equipo maduro (por ejemplo, con miembros muy capacitados y que ha estado trabajando juntos durante un período de tiempo justo).
En2020, Luca Rossi reflexionó en un blog sobre los comentarios de Ward Cunningham (inventor original del término “Deuda Técnica”) sobre cómo esta no se relaciona realmente con el código “sucio” o “malo”, sino con la falta de cumplimiento de los requerimientos (implícitos y explícitos). También propone 2 razones por las que esto sucede y cómo lidiar con ellas de una manera “saludable”.
Por lo tanto, siguiendo la línea de pensamiento de Rossi y Ward, en el próximo artículo introduciré el concepto de Deuda de Calidad.
¡Manténgase en sintonía!