Deuda técnica en desarrollo de software

¿Qué deuda? Si yo no te debo nada, ya te pagué lo del almuerzo; dijo el project manager… ¡La deuda técnica! expresó el programador.

El chiste fácil, broma en equipos de scrum

¿Qué es la deuda técnica en software y cómo afecta a tu ecommerce?

La deuda técnica en software se produce cuando se toman atajos en el desarrollo de una funcionalidad o decisiones a corto plazo en la construcción de una solución informática, en lugar de utilizar los mejores métodos y prácticas recomendadas.

Cuando los costos son magros y los plazos apremian, es evidente que se caerá en acortar caminos, hacer menos testing, derivar el desarrollo al camino más corto y simplificar. Probablemente termine en un equipo junior y se genere una situación que deba retomarse más adelante.
Deuda técnica en ecommerce, desarmar la bomba a tiempo (Zoom)
Tweet

A medida que el software crece y evoluciona, esta deuda se acumula y puede afectar la calidad y eficiencia del sistema. Otras veces no se acumula y afecta en rendimiento, sino que se deja un MVP o un «atado con alambre» eterno y se necesita tarde o temprano continuar el desarrollo, extender los alcances, cubrir más casos de uso, etc.

¿Por qué se produce la deuda técnica?

La deuda técnica se produce por diversas razones, como la falta de tiempo o recursos para hacer las cosas bien desde el principio, la falta de conocimientos técnicos, la presión por cumplir plazos o la falta de planificación.

Las decisiones a corto plazo pueden generar problemas a largo plazo, aumentando los costos de mantenimiento y actualización del software.

Si tenemos que desarrollar algo que llevaría 4 meses, en tan solo 2 meses, evidentemente debemos recortar cosas que nos permitan llegar a la entrega y sea medianamente funcional.

Dos ejemplos sencillos de deuda técnica en software

Un ejemplo podría ser si en una integración solo hace un intento, sin una política de reintentos. Si algo falló, el sistema se cae, se reinició una máquina, etc, no se reintentará, salvo se manipule manualmente algo que lo produzca.

Otra es la programación lineal que no tiene gestión de errores: algo falló, pero no sabemos bien qué ni donde. No se agregaron logs, no se agregó una alerta, no se hacen reintentos ni correcciones en formatos para evitar el atasco.

También hay otro tipo de deuda técnica que tiene que ver con las actualizaciones de versión en sistemas o lenguajes de programación

Sistemas que aún usan la versión de lenguaje de programación PHP 5.6, cuando desde hace tres años ese lenguaje va por la versión 8, mucho más estable, escalable, segura, consume casi la mitad de memoria y procesador.

En consecuencia, invertir en actualizar el sistema, sus lenguajes, librerías, se equilibra pagando menos costos de infraestructura.

Y lo mismo con los servidores: pasar de discos duros a SSD o NVMe, que son 10 y hasta 10.000 veces más rápidos que los antiguos.

No creo que a esta altura las empresas que se plantean iniciar un ecommerce sigan discutiendo si usar máquina de escribir con carbónico o tener computadoras con una impresora láser. Eso es deuda técnica de hardware.

¿Cómo reducir o evitar la deuda técnica?

Para reducir o evitar la deuda técnica, es necesario implementar buenas prácticas de desarrollo de software:

  • uso de metodologías ágiles,
  • diseño modular y escalable,
  • documentación del código y funcional,
  • Clean Code, Principios SOLID, y otras metodologías.
  • implementación de pruebas: automatizadas, unitarias, end to end, de integración, funcionales.

También es importante realizar una planificación adecuada, para ello deben incluirse perfiles como líder técnico, programadores senior, product owner y product managers, y además contar con el tiempo y recursos suficientes para realizar el trabajo de manera eficiente, de acuerdo a estimaciones y criterio/seguimiento del project manager.

¿Cómo manejar la deuda técnica con el paso del tiempo?

Es importante manejar la deuda técnica a medida que se va acumulando.

Muchos Scrum Master o Project Manager planifican un «sprint de revisión» donde asignan a todo el equipo o algunos programadores a poner al día lo más prioritario o potencialmente riesgoso a resolverse. También se debe tener documentado cuáles pueden ser los puntos calientes o de conflicto en el proyecto, de mediano y largo plazo.

Tener todo montado en un sistema de control de versiones como GIT, ayuda mucho a comprender los problemas. Pero sin una documentación y seguimiento, acuerdos y motivación a desenredar y desandar lo necesario, no es posible reducir o prevenir la deuda técnica.

Una forma de hacerlo es a través de una estrategia de refactorización regular, que consiste en mejorar el código existente sin cambiar su comportamiento. Este enfoque puede darse «de pasada», como rutina, ya cuando alguien detecta oportunidades de mejora mientras hace otro desarrollo. También en tiempos libres o calendario muerto de un proyecto.

También es importante realizar actualizaciones regulares del software y utilizar herramientas de monitoreo y análisis para identificar posibles problemas. Hay plataformas que analizan tanto el código, test y performance, que con inteligencia artificial van sugiriendo puntos de análisis o cambio.

En resumen, la deuda técnica es una realidad en el desarrollo de software, pero puede ser reducida o evitada mediante la implementación de buenas prácticas y una planificación adecuada. Es importante manejar la deuda técnica con el paso del tiempo para mantener la calidad y eficiencia del software de tu ecommerce.