En términos simples, la deuda técnica tiene que ver con el tiempo que tendrías que invertir para solucionar problemas que estás dejando de lado a nombre de generar un resultado en el menor tiempo posible.

Sí, con esto me refiero a las consecuencias del “déjalo ahí, luego lo arreglamos”

Lo que me he encontrado es que esa es una frase que es aceptada hasta que los problemas se empiezan a poner serios. Por otro lado, hay que considerar que si queremos mejorar “algo”, pues tenemos que saber cómo medir ese “algo” antes y después de los cambios realizados.

¿Cómo mido un sistema?

Estoy seguro de que hay muchas formas para eso, pero aquí los pasos que sigo regularmente:

1. Perspectiva del usuario final
2. Comportamiento en tiempo real (análisis dinámico de código)
3. Perspectiva del desarrollador (análisis estático de código)

1. Perspectiva del usuario final

Asumiendo de que el usuario está contento con las funcionalidades existentes y de que no hay errores en producción (Sí, es un gran supuesto), lo que normalmente sugiero es tomar nota del comportamiento de la aplicación.

¿Qué se hace ahí? Pues se mide lo que llega al usuario ¿Cómo medimos la aplicación? Para nuestra suerte, si estamos trabajando con una aplicación web, existen herramientas gratuitas que nos permiten tener reportes como el que nos genera [GTmetrix]

Parece obvio, pero les cuento que he estado en proyectos en los que no se había considerado una revisión bajo esa perspectiva y ya se tenían quejas de que “el sistema estaba lento”

Lo bueno de herramientas como GTmetrix, es que brindan una mirada objetiva de lo que le entregas al consumidor final. Aquí es donde encontrarás aspectos como el tiempo de carga de la página (Fully Loaded Time) o incluso el tamaño de lo que se descarga al navegador (Total Page Size)

Por otro lado, GTmetrix incluye una serie de análisis usando herramientas como [PageSpeed] o [YSlow]. Para ambos casos se genera un score que puede mejorarse si sigues las recomendaciones que, para tener una idea, se crearon bajo estándares de Google (para el caso de PageSpeed) o Yahoo! (para el caso de YSlow)

Otra opción interesante viene con Google Chrome y se puede usar desde la opción Developer Tools/Audits, lo cual, en resumen, hace uso de [Lighthouse], que también es usado por Google PageSpeed 🙂

Los que me conocen saben del cariño que le tengo a YSlow y que me apena que ya no haya una extensión de navegador para hacer un análisis a ese nivel de detalle. Tiempos aquellos 🙂

Update: Si pueden denle una oportunidad a https://yellowlab.tools/ Se ve muy interesante!

2. Comportamiento en tiempo real (análisis dinámico)

Una vía rápida para reaccionar a lo que le ocurre al sistema, es saber lo que le pasa a este mientras va funcionando. No soy partidario de esta forma de trabajo, pero en sistemas que ya se están ejecutando en producción es importante contar con al menos una herramienta que permita tener una vista de ese tipo.

Aquí es donde hablamos del análisis dinámico del código con herramientas del tipo APM (Application Performance Monitor). Una que hace muy bien ese trabajo es [New Relic]

La importancia de este tipo de herramientas radica que no son invasivas. Es decir, no tienes que tocar tu código y la performance de la aplicación no se ve afectada. Antes de New Relic probé otros analizadores que degradaban la aplicación al punto que decidíamos desactivar el analizador.

3. Perspectiva del desarrollador (análisis estático)

Tal como mencioné en la sección anterior, no soy partidario de ir reaccionando acorde a lo que le ocurra al sistema pues creo firmemente que la mejor forma de solucionar un problema es evitándolo.

Bajo esa premisa estamos en la obligación de encontrar mecanismos que permitan controlar lo que se está construyendo o modificando. Aquí es donde entran herramientas como [SonarQube]

Lo bueno de esta herramienta (entre muchas cosas) es que te ayuda a clasificar los posibles problemas de programación y te da una estimación base de lo que necesitarías para cubrir esa deuda técnica.

¿Qué ocurre normalmente?

Lo que he encontrado en algunos proyectos es:

1. No se mide lo que se está construyendo
2. Se mide lo que se construye pero en términos de deuda técnica convencional (análisis estático con SonarQube)

No pondré en duda si se toma acción sobre la deuda técnica pero lo que regularmete encuentro es que se pierde la perspectiva de lo que ocurre en producción o se hace a consecuencia de un problema.

¿Qué estamos perdiendo?

No soy un experto en el tema pero les puedo asegurar que poco a poco iremos perdiendo el control de nuestra aplicación analizada. No he encontrado un estudio detallado del impacto financiero al respecto, pero valgan verdades hay situaciones en las que el equipo de desarrollo sugerirá rehacer un componente/servicio/módulo/aplicación a consecuencia de que lo encontrado es inmantenible.

¿Se imaginan eso en términos financieros? Pues ahí un primer vistazo al dinero perdido a consecuencia de una deuda técnica mal gestionada.

¿Qué tenemos que hacer?

La primera respuesta es obvia, “tenemos que medir nuestra aplicación” pero en realidad, además de invertir para lograrlo, hay mucho por hacer al respecto pues lamentablemente no he encontrado una herramienta que nos muestre lo que es realmente la deuda técnica. Si bien es cierto SonarQube nos da una idea al respecto, pero no podemos confiar en ese único indicador (Resumen, SonarQube te ayuda pero no es la solución definitiva ☹️)

La segunda respuesta tiene que ver con lo que algunos llamamos el diseño y ejecución de nuestro plan de pagos. Es decir ¿cómo vamos a ir pagando nuestra deuda técnica?

Es aquí donde tenermos una [gran responsabilidad], pues además de englobar esta serie de issues/riesgos/problemas/bugs tenemos que darle forma al indicador y a su impacto técnico/financiero. Por otro lado, debemos aceptar que siempre estará ahí pues estoy seguro de que no hay proyecto que elimine la deuda por completo. Es decir, siempre habrán issues con los que tendremos que convivir, pero si es así, tiene que ser una convivencia sana 🙂

Un abrazo,