¿Estamos jugando Jenga con nuestros sistemas?

Si trabajamos en el mundo de la tecnología, ya nos debe haber pasado –o escuchado– de que el sistema se cayó por un cambio mal realizado. A veces nos pasa que mientras arreglamos una cosa malogramos otras. Mucho cuidado con los círculos viciosos.

Estas situaciones me recuerdan las veces que juego [Jenga] con mis amigos. Y es que, de empezar con una mala estrategia, llegado un punto, cada turno se vuelve emocionante pues nadie quiere tumbar la torre de madera.

Fuente: [Wikimedia]

Si en los proyectos de tecnología empezamos sin una estrategia técnica adecuada, muchas veces tendremos dolores de cabeza en el futuro. Sin ir muy lejos, muchas decisiones técnicas son pasadas por alto a consecuencia de “ahorrar”, “lo arreglamos después”, “las cosas siempre fueron así” o la necesidad de solucionar problemas rápidamente sin entender por completo las implicancias del mismo o incluso sin entender la solución.

Sinceramente creo que pasar por este tipo de situaciones nos hacen crecer profesionalmente. Sin ir muy lejos, con el paso del tiempo he descubierto que ya no me gustan algunas soluciones que hice en proyectos anteriores, la idea es ir descubriendo nuevas formas y cuestionar nuestro trabajo. Creo que deberíamos ser los primeros en hacerlo.

Regresando a la analogía, les cuento que conversando con muchos amigos o con las personas que me entrevistaban mientras buscaba trabajo, he confirmado mi teoría; todos hemos tenido una torre de Jenga que se ha derrumbado al menos una vez en nuestros sistemas. A veces nos reímos de eso y otras nos avergüenza, pero lo más importante es que hemos tenido la capacidad de aprender y jugar sabiamente.

¿Qué síntomas tienen los sistemas Jenga?

  1. Los pases a producción tienen correcciones de última hora. O bueno, las correcciones del día siguiente.
  1. Es común hacer rollback pues las correcciones tardarán demasiado.
  1. Es común escuchar el [por favor, no toques ese código]
  1. Hay una persona que puede resolver los problemas “difíciles” y algunas veces ese es su trabajo principal. En algunos casos su rol o título es “el especialista”
  1. La gestión de versiones es pobre o nula.
  1. Los pases a producción se ejecutan manualmente.
  1. Las pruebas se hacen “a mano”
  1. La documentación no está actualizada o bueno, no existe.

Tal como dije al empezar con este post, puede que nos hayan pasado estas cosas y no hay problema con ello. Lo que sí creo es que sería irresponsable no hacer algo al respecto para que esto no nos vuelva a ocurrir.

¿Qué es lo que podemos hacer?

Puede que este sea –o suene– un trabajo complicado pero no es imposible. Los factores de éxito más importante tienen que ver con la determinación para resolver los problemas y el tiempo necesario para empezar con este tipo de trabajos.

A pesar de ello, he dividido esta estrategia en tres etapas.

#1: Orden

  1. Si no cuentan con una gestión de versiones adecuada o no han explorado ese camino, pues Git sobre GitHub es un excelente punto de partida. No se compliquen la vida pensando en qué archivos agregar al gestor de versiones, la depuración será parte del trabajo a realizar. Si no están familiarizados, aquí algunas referencias a tener en cuenta:
  1. Identifiquen el código innecesario, para no perder mucho tiempo en este paso, tienen que trabajar con herramientas como [SonarQube]. En mi publicación de [código muerto] encontrarán más detalle al respecto.
  1. Limpien su código fuente aprovechando la información encontrada en el paso anterior. Como mencioné en [código muerto], un buen calentamiento es comenzar por esas carpetas y archivos que nadie usa. Descubrirán que es un trabajo divertido y que en el tiempo resulta motivador ver cómo el código se va limpiando de a pocos y claro, los indicadores de SonarQube van reflejando el resultado de nuestro esfuerzo.
  1. Busquen que los especialistas en resolver problemas sean los primeros candidatos a ser referentes técnicos. Estoy seguro de que encontrarán de que hay experiencia que no está correctamente enfocada. Los especialistas podrán ayudar a identificar y/o eliminar esos elementos muertos y mejor aún, cumplir con labores más interesantes.
    • Ojo que esta actividad también nos servirá para confirmar si nuestros especialistas están preparados para dar el próximo paso o quizá es que no están interesados en hacerlo.
  1. Hablemos de automatizando. Un paso muy importante es engranar el desarrollo con un servidor de automatización y uno de los más populares es [Jenkins]. Lo mínimo necesario es implementar un flujo de [Integración Continua] y si todo marcha bien, ir pensando en la [Entrega Continua]. No se apuren en cumplir todas las recomendaciones que puedan encontrar en la web, con el paso de cada de actividad descubrirán qué paso agregar u omitir en el flujo de automatización.
  1. Identifiquen el código de las funcionalidades más importantes para el negocio. Aquí es donde los referentes técnicos nos darán una mano o en el peor de los casos, confirmarán que alguno de ellos solo se había orientado a resolver problema sin entender las causas o impacto en el negocio. Si esto ocurre no se preocupen, siempre habrán cosas por mejorar pero dependeremos mucho de la actitud de los involucrados.
  1. Automaticen sus pruebas. Es posible que hayan escuchado que es un trabajo interminable o que pone en riesgo las fechas comprometidas pero hay que sincerar las cosas, en un primer intento no podremos automatizar todo. Aquí es donde veremos la importancia de haber identificado las funcionalidades más importantes. La primera versión de esta automatización no tiene que ser perfecta pero debe existir alguna forma sencilla de validar las más importantes. Lo más importante radica en que el equipo decida el número mínimo de pruebas a automatizar. Aquí dos consideraciones a tener en cuenta:
    • Si no tienen el tiempo necesario, pueden empezar con [pruebas unitarias], cuya tecnología dependerá del stack tecnológico con el que cuenten.
    • Si quieren dar un paso más adelante y están trabajando sobre una plataforma web o servicios REST, pueden realizar pruebas usando [cypress]
  1. Refactoricen, sigan limpiando, midan el avance. Herramientas como [SonarQube] o [New Relic] les darán una serie de pistas que los ayudarán a seguir limpiando el código. No tienen que seguir todas las recomendaciones, la idea es ir mejorando la calidad del código mientras van construyendo nuevas funcionalidades, siempre recordando que las pruebas automatizadas nos indicarán si estamos rompiendo algo que ya funcionaba.

#2: Equipo

  1. Busquen alinear los conocimientos del equipo. Si bien es cierto este es un ideal, lo mínimo esperado es que los especialistas compartan lo necesario para ir cortando dependencias. Lo que necesitamos es tener más jugadores de equipo y de paso confirmar si los especialistas se pueden afirmar como referentes técnicos (una forma de hacerlo es creando espacios donde puedan compartir lo que saben)
  1. Promuevan más reuniones técnicas. La temática puede estar relacionada a un problema, una solución, una técnica de programación, un sistema o una tecnología en particular. Consideren que también podrían invitar a personas de otros equipos o empresas (para compartir algún tema como los mencionados)
  1. Promuevan la capacitación del equipo. Ser autodidactas es bueno, pero si está a nuestro alcance gestionar o solicitar ese capacitaciones para el equipo, es nuestra responsabilidad hacerlo. Estas sesiones deben considerar aspectos prácticos. Para ser claros, toda teoría debe complementarse con un ejemplo que empuje al equipo a escribir código. Aquí unos tópicos que sugiero regularmente:
    • Programación orientada a objetos
    • Algoritmos de búsqueda
    • Teoría de complejidad
    • Pruebas unitarias
    • Refactorización
    • Test Driven Development
    • Automatización de pruebas
    • Servidores o servicios de automatización
  1. Evalúen. Esto se debe realizar de manera continua mientras se vaya realizando la capacitación y debe confirmarse con una evaluación final, la cual debe ser con computadora en mano. Con esto confirmarán si el objetivo de la capacitación se ha cumplido.
  1. Definan con el equipo las nuevas reglas del juego. El equipo seguirá desarrollando las funcionalidades requeridas por el negocio pero en adelante debería haber apertura para:
    • Refactorizar el código existente sin romper las pruebas unitarias ya construidas
    • Implementar nuevas pruebas unitarias, además de la relacionada a la nueva funcionalidad a construir
    • Eliminar código muerto
    • Gestionar la deuda técnica sin ser perfeccionistas

#3: Visión

Hay que tener en cuenta de que estamos trabajando sobre la practica de ir mejorando lo existente mientras seguimos atendiendo la misión del negocio. Esto es lo que ocurre normalmente, no debemos olvidar la visión del negocio y que además esta nos sirve como referencia principal de nuestra visión tecnológica. Lo que he encontrado en algunas situaciones es que también hay mucho trabajo por realizar, aquí algunas consideraciones:

  1. ¿Tenemos un diagrama de situación actual? No se preocupen, lo normal es que ese diagrama no exista. La buena noticia dependerá de qué tan bien hayamos seguido la práctica de realizar reuniones técnicas. Si la respuesta es positiva, lo que debe hacer el equipo es dibujar el primer diagrama AS-IS de los sistemas de la empresa. Estas sesiones también servirán para crear una lista de aquellas cosas por refactorizar/mejorar, la cual debe estar relacionada con cada elemento identificado en el diagrama.
  1. Es momento de definir nuestros compromisos técnicos. Lo normal es tener objetivos técnicos (p.e. reducir los errores en 25%) mientras que los compromisos muchas veces se omiten o se consideran implícitos. Lo mejor es aclarar en conjunto aquellos compromisos que en adelante se respetarán por la salud técnica de nuestros sistemas. Aquí una propuesta:
    • Funcional: Fácil de usar (perspectiva del usuario)
    • Flexible: Fácil de entender y modificar (perspectiva del desarrollador)
    • Extensible: Fácil de conectar con otros sistemas (perspectiva del desarrollador y del sistema)
    • Automatizable: Lo necesario para poder compilar, probar, desplegar y diagnosticar fácilmente.
  1. ¿A dónde queremos llegar? El objetivo de esta actividad es obtener un diagrama TO-BE teniendo en cuenta lo siguiente:
    • Podemos soñar
    • Debemos considerar que tenemos al menos dos inputs técnicos, el diagrama AS-IS y la lista de cosas por refactorizar/mejorar
    • Un input adicional –y que no es técnico– es la visión del negocio ¿qué es lo que se está buscando en 3, 5, 10 años? Mientras más información tengamos, mucho mejor
    • ¿Podemos soñar? Claro que sí pero tampoco creamos que de un día a otro conseguiremos arquitecturas como las que promueven Amazon, Netflix, Uber o tantas grandes empresas.
    • Debemos considerar que en el tiempo nuestra torre se debe transformar en una fortaleza. Lo ideal es derrumbar todo y empezar de nuevo pero eso sí sería soñar en grande.
  1. Seamos realistas. No me malinterpreten, lo que quiero decir es que debemos hacer una comparación entre lo que tenemos y lo que buscamos y sobre eso hagamos un plan que busque eliminar ese gap poco a poco.
    • Tengamos en cuenta de que cada paso se debe convertir en al menos una meta a cumplir y que cada meta debe ser fácil de medir en un tiempo determinado.
    • Por otro lado si es que no tenemos opción a reemplazar todo un sistema. Lo que podemos hacer es hacer el reemplazo de aquellos componentes que a veces vale la pena reemplazar por un nuevo desarrollo o por algo que podríamos comprar y modificar. Si esto se puede hacer para varios elementos de un sistema, es un proceso que le he llamado “reemplazo silencioso del sistema”
    • La deuda siempre existirá y sigamos trabajando con eso. No tenemos que ser perfeccionistas, [la regla del 80-20] siempre ayuda.

Comentarios finales

Lo que he encontrado en algunos equipos es que con el paso del tiempo nos volvemos jugadores expertos de Jenga y la verdad es que eso es algo que no deberíamos buscar. No es saludable.

Lo que también he encontrado es que una definición incorrecta del trabajo a realizar –para atacar la torre de Jenga– hará que no se encuentre o vea el valor de lo que estamos buscando. Parte de esto lo menciono en [la importancia de la arquitectura de un sistema]

Algo muy importante –y obvio para algunos– es que necesitarán más jugadores de equipo y menos jugadores de Jenga.

Un abrazo,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.