El arte de posponer

El tema sobre el que os voy a hablar hoy no es nada que yo haya inventado ni mucho menos, simplemente quiero contar mi punto de vista después de vivir una experiencia que sin duda cambiaria mi forma de trabajar en el futuro.

Nos gusta complicarnos la vida

El mundo del desarrollo es un sector al que le gusta complicarse la vida cuando es necesario solucionar un problema para cubrir una necesidad. Ejemplos de esto que comento hay miles, algunos ejemplos:

  • Necesitamos autenticar a los usuarios y nos montamos un Single-Sign-On, o peor aun una BBDD para gestionar usuarios.
  • Necesitamos persistencia y nos montamos un Mongo/Postgres/MySQL, etc.
  • Necesitamos una API y un cliente que la consuma y montamos un par de microservicios.

¿Creo que se entiende la idea, no? De una forma completamente inconsciente y con las mejores intenciones es muy habitual que siempre elijamos la solución más complicada para solucionar nuestros problemas cuando sería posible conseguir el mismo resultado con una idea infinitamente más sencilla.

¿Y si no hace falta complicarse tanto?

Debido a que estos últimos meses me encuentro trabajando en un entorno de mejora continua con una forma de trabajar muy Lean en poco tiempo comencé a leer y escuchar acerca de Defer Commitment.

Esta forma de trabajar es tan sencilla como efectiva y viene a decir que tratemos de evitar tomar decisiones irreversibles (o muy difíciles de revertir) durante el mayor tiempo posible.

Personalmente me gusta definir este enfoque como tratar de utilizar la solución más sencilla durante el mayor tiempo posible hasta llegar a un punto en el tiempo en el que otra solución algo más compleja tenga más sentido.

Como veis la teoría es “sencilla”, ¿entonces porque nos solemos complicar en exceso? Sinceramente no lo sé, pero tengo varias teorías al respecto como que nos gusta solucionar problemas difíciles, que nos va la marcha y que esta forma de trabajar tan Lean es muy difícil de encontrar en las empresas.

Ejemplo práctico (y real)

La idea de escribir este post nace de unos de esos momentos donde todo encaja, donde vi en práctica toda esa teoría de la que tanto había oído, visto y leído.

Para mí fue un momento muy importante porque por mucho que leas, veas charlas o tengas conversaciones sobre un tema hasta que no lo veas materializado en algo concreto no es lo mismo. Para ello voy a hablar de un ejemplo real (algunos detalles han sido alterados por temas de confidencialidad).

Imaginemos que como equipo tenemos que crear un bot para Telegram el cual aceptara una serie de comandos que realizaran acciones como realizar una release, crear una cuenta de Gmail, abrir un ticket en Jira, crear un usuario en AWS, etc.

Uno de los requisitos de este bot es que debemos delimitar el acceso a los comandos para determinados usuarios, algunos serán públicos para todo el mundo pero habrá otros que solo podrán ser ejecutados por determinados usuarios.

¿Imagino que ya estaréis pensando por donde voy, no? Un porcentaje muy alto de gente optaría por montar un sistema de autenticación, como podría ser una base de datos con una serie de tablas que nuestro bot usara como fuente de verdad.

Este enfoque, que repito es el más habitual, tiene una serie de problemas que nos harán ir más lentos de cara a entregar valor pronto:

  • Necesitamos montar una base de datos, con el coste añadido que tiene.
  • Debemos desarrollar la lógica para conectar nuestro bot con este BBDD.
  • Habrá que tener una BBDD por entorno.
  • Uno sistema de back-ups será necesario para estar cubiertos en caso de catástrofe.
  • ¿…sigo?

¿Y si os digo que con una par de ficheros (uno con comandos asociados a grupos de usuarios y otros con grupos de usuarios) podemos obtener el mismo resultado?

  • Sin montar una base de datos.
  • Usando el control de versiones del repositorio como back-up
  • Simplemente leyendo su contenido cuando necesitemos saber si un usuario tiene permiso para ejecutar un comando.

Pues os puedo decir no solo que es posible, sino que este ejemplo “tonto” fue una solución que estuvo funcionando durante más de un año de forma espectacular hasta que se decidió que era el momento de mejorar este sistema debido a que el estado de la empresa ya era otro mucho más maduro y con mucha más gente.

Conclusiones

Para mí este caso real de posponer decisiones lo máximo posible y optar por la solución más sencilla, ha sido un punto de inflexión en mi carrera profesional y que sin duda ha cambiado mi forma de afrontar este tipo de situaciones.

Espero que os haya gustado este post y que leer hacer de un caso real os ayude a ver que esta forma de trabajar es posible.