Deuda técnica, lección aprendida

Una de las frases más sabias que hemos escuchado en Transparent Edge surgió de una de las personas con más experiencia en desarrollo y construcción de software a la que hemos tenido acceso: “las prisas pasan, las mierd** quedan”.

Es cierto que las palabras utilizadas no son las más adecuadas (que me perdonen los lectores por la transcripción literal), pero su esencia refleja un problema complejo al que se enfrentan la gran mayoría de empresas que utilizan tecnología: la gestión de la deuda técnica.

¿Qué es la deuda técnica? ¿Ahora le debo dinero al ordenador?

No exactamente, pero funciona de una manera similar a la deuda monetaria. Deuda técnica es el concepto que refleja el coste que tiene una decisión técnica donde se prima la solución fácil y rápida respecto a la óptima. Este coste implica un trabajo extra en el futuro, ya que tarde o temprano tendremos que dedicar recursos adicionales para compensar el parche con el que hemos salido del paso. En algunas ocasiones, la deuda adquirida puede generar “intereses”, y cuanto más tiempo pase, mayor será el esfuerzo de revertir las soluciones improvisadas.

Entonces, ¿para qué hacerlo? Es malo endeudarse, ¡lo ha dicho Merkel!

En realidad no tiene por qué y muchas veces viene impuesto por la propia situación. Sobre todo en productos por validar o en software ya en producción, cuando la velocidad en la implementación o resolución de problemas es crítica. Una funcionalidad perfecta que llega tarde no vale nada, pero una funcionalidad cogida con alfileres que llega a tiempo puede resolver el caso con éxito. Cuando esto sucede, el equipo opta por endeudarse técnicamente, tomando decisiones mejorables a cambio de sacar el proyecto adelante. De alguna manera, pedimos prestado tiempo al futuro para resolver lo que es  imprescindible ahora. 

La deuda técnica en sí misma no es mala, pero la persona que gestiona el proyecto debe ser consciente del compromiso que adquiere con la tecnología, sabiendo que tendrá que pagar su decisión tarde o temprano. Olvidar esta deuda o dejarla aparcada sine die es garantía de problemas futuros, aquí no hay condonación que valga. Con el stack tecnológico hay que ser como los Lannister de Juego de Tronos y pagar SIEMPRE las deudas.

¿Y si se me olvida pagar?

Esto puede pasar, nosotros lo sufrimos recientemente. Un poco de deuda técnica adquirida muy al principio del desarrollo de la CDN nos dio un buen susto.

Nuestro proceso de conteo de ancho de banda y request tiene muchos engranajes, pero se hace básicamente a partir de los logs de los nodos que sirven el contenido. Varios procesos toman esos logs, extraen la información relevante y la almacenan en bases de datos, donde se consultan los procesos de facturación y la API de Transparent Edge. Este dato es lo que llamamos single source of truth, un punto de referencia único sobre el consumo de nuestros clientes.

Al ser  un proceso tan crítico, está monitorizado y nos aseguramos de tener la observabilidad necesaria para detectar cualquier incidencia. Por eso mismo, cuando uno de los resúmenes diarios que se agregan por correo nos llegó con estos datos, no dábamos crédito:

Lo primero fue comprobar si efectivamente este error se había escrito a base de datos y estábamos ofreciendo cifras incorrectas a nuestros clientes y al sistema de facturación. Por suerte, no era así y los datos estaban correctamente escritos. ¿Qué ocurría entonces? ¿Por qué estábamos reportando datos incorrectos?

Pagarás antes o después, eso seguro

La respuesta, como podéis imaginar leyendo este post, se enmarca en una deuda técnica que adquirimos en el pasado. Cuando dije que teníamos un single source of truth para los consumos, no estaba siendo totalmente sincero. Al construir el agregado por correo, acabábamos de hacer el proceso de consolidado, y la persona que estaba trabajando en ello -ejem, no fui yo; fue una amiga- decidió tomar un atajo en ese momento.

En vez de recoger los datos recién insertados,utilizó el log del proceso, donde ya estaba la suma total, para tirar un par de grep y simplificar el script. Ya sabemos cómo es el lado oscuro: más rápido, más fácil, más seductor.

Lo que ocurrió, años después, fue una subida que modificaba el logging de muchos de nuestros procesos, precisamente para mejorarlos y aportar más información en caso de problemas. Fue una subida impecable y todos los procesos estaban adaptados al nuevo formato. ¿Todos? No. El técnicamente moroso agregador por correo estaba consultando donde no debía, dándonos un buen susto a todos. Había llegado la hora de pagar, y hacer las cosas bien.

The North remembers, and so does your code.

Diego Suárez es director de Tecnología de Transparent Edge.

Si alguna vez buscas a Diego, lo encontrarás con casi toda probabilidad donde haya un sistema operativo y no lo hallarás buscando el camino fácil, sino afrontando la alternativa más compleja. Estar siempre en el filo de la navaja le confiere la versatilidad y la visión necesarias para desarrollar la estrategia de tecnología que es el centro gravitacional de Transparent Edge. A caballo siempre entre desarrollo y sistemas, no por ello ha dejado de lado otras áreas, preocupándose por mantener el contacto con el usuario, que es para quien trabaja toda empresa tecnológica.