Por qué y cómo fallar rápido y con propósito

Imagina la siguiente situación. Un equipo trabaja en Sprints de 3 semanas. El desarrollador invierte unas dos semanas y media escribiendo código, y el tester media semana probándolo. El desarrollador continúa trabajando bajo el supuesto de que lo que ha hecho hasta ese punto funciona correctamente, así que construye sobre lo que hizo durante las primeras dos y media semanas. Pero cuando llega al inicio de la cuarta semana, el tester reporta una docena de bugs. Ahora el desarrollador no sólo debe corregir los bugs, sino retrabajar lo avanzado. Más aún, podría estar reticente a andar por el mismo camino, de modo que el producto final será más parecido a un conjunto de parches que a un todo coherente.

¿Suena familiar? A pesar de la aversión que le tenemos al fracaso, aquí es donde fallar, pero fallar de manera controlada y a tiempo, puede ser de utilidad. La idea de fallar rápido va de la mano del conjunto de prácticas DevOps, (o “desarrollo” más “operaciones”), caracterizado por los principios de propiedad compartida, automatización del flujo de trabajo y retroalimentación rápida. El punto de fallar rápido es recibir retroalimentación y aprender de ella lo antes posible, y como veremos más adelante, esto se puede lograr en parte por medio de la automatización.

Un medio ambiente que motive la experimentación

Otro motivo por el cual nos conviene fallar pronto es que serán errores pequeños y manejables; más aún si los esperamos de antemano. Como observa DeLisa Alexander, “fallar rápido normalmente equivale a fallar en cosas pequeñas en lugar de fallar en grande. Si constantemente proponemos nuestras ideas, escuchamos cómo las reciben otros y las mejoramos, la mayor parte del tiempo podremos evitar el tipo de fracaso que realmente tememos: grande, catastrófico, monumental, vergonzoso”.

Pero para ello se requiere de una cultura que permita experimentar sin miedo al fracaso; un ambiente que valore el aprendizaje por medio de la prueba y el error. Después de todo, la perfección es imposible, y en sistemas complejos como los que creamos en el ámbito de las tecnologías de la información, más vale aceptar que habrá fallos y convertirlos en nuestros aliados que correr en sentido contrario. Dicho por Twain Taylor, la experimentación permitirá al equipo de desarrollo fallar más rápido, y mientras más rápido falle, más rápido pueden descubrir maneras de mejorar sistemas y productos.

El experimento del "reto del malvavisco" (marshmallow challenge) diseñado por Peter Skillman y popularizado por Tom Wujec ilustra esta idea: Diversos grupos de personas recibieron 20 palillos de espagueti, un poco de cinta adhesiva, un poco de hilo y un malvavisco. El objetivo del reto era construir una estructura de espagueti que elevara el malvavisco lo más alto posible. Lo interesante es que el grupo de estudiantes de negocio quedó en último lugar, al parecer porque desperdiciaron demasiado tiempo discutiendo quién sería el líder. A los ingenieros les fue mejor, pero no obtuvieron el primer lugar. Fue un grupo de niños pequeños quienes ganaron, porque no perdieron el tiempo y se pusieron manos a la obra a descubrir lo que resultaba mejor.

Creo que podemos suponer que los infantes no tenían miedo a represalias y que el ánimo de juego les dio inspiración. Naturalmente, no somos niños, pero deberíamos aspirar a un ambiente de trabajo que permita ciertas cualidades normalmente consideradas infantiles: el descubrimiento, la experimentación y la ausencia de miedo a un resultado negativo.

¿Cómo traducir la cultura de la experimentación al terreno operativo?

Una vez que una organización se encuentra permeada por la cultura de la experimentación y del fallo rápido, manejable y controlado, debemos traducirla a políticas y prácticas concretas. Un modo de hacerlo es “liberar pronto y seguido”, en palabras de Alexander. Yo pienso que un fragmento de código está listo para ser liberado y probado tan pronto como haga algo, cualquier cosa, por sencilla que sea. Si el valor de un campo determina si la siguiente sección de una página se abre o no, es suficiente para que un par de ojos aparte de los del desarrollador le echen un vistazo, comprueben que esa parte del código funciona, y quizá incluso haga sugerencias. Como lo explica Haff, desde la perspectiva de DevOps, debemos hacer liberaciones de manera incremental, rutinaria y frecuente, de ser posible realizando despliegues pequeños, autónomos y de servicios delimitados por su contexto; por ejemplo microservicios o patrones similares.

Otro punto clave es la comunicación continua. No dejemos al desarrollador caer en la tentación de “enchufarse a la computadora y aventar código” sin que comparta con su equipo lo que está haciendo.

Aquí no estoy diciendo nada nuevo; las metodologías de desarrollo ágil contemplan reuniones diarias o dailys de no más de quince minutos para mantener a todo el equipo en la misma página. Como indica Taylor, lo deseable es “un ambiente colaborativo en el que los empleados involucrados en diferentes etapas del proceso puedan entrar en cualquier fase del desarrollo del producto y su despliegue gracias a su conocimiento y habilidades compartidas que permitan que el pipeline corra sin problemas”.

De relevancia tanto para la cultura laboral como para las prácticas operativas son los incentivos. La clave, dice Haff, es que por medio de los incentivos el individuo tiene control sobre su propio éxito, al recibir reconocimiento, ya sea económico, profesional o de algún otro tipo, como recompensa a la confianza, la cooperación y la innovación.

Herramientas tecnológicas para fallar rápido

Como señalé arriba, la automatización puede ayudar con este proceso. De entre las herramientas disponibles me gustaría recomendar dos de las más populares, ambas open-source: Selenium y Appium.

• Selenium es un software que automatiza tareas en un navegador. Naturalmente su mayor utilidad se encuentra en el terreno de pruebas, aunque no se limita a ello. Podríamos pedirle a un tester que llene manualmente un formulario de siete pantallas, cada una con 50 campos, y hacer que invierta unas tres horas de su tiempo por prueba. O podríamos pedirle al tester que invierta esas mismas horas en aprender Selenium y programar sus tareas de pruebas, mismas que pueden ser repetidas n veces y en menor tiempo por prueba, de manera que el desarrollador obtendría retroalimentación más eficazmente. Los scripts de las pruebas de Selenium pueden escribirse en una variedad de lenguajes, como Java, C# y Python, lo que facilitaría la curva de aprendizaje del tester.
• Appium es el equivalente de automatización de Selenium para apps de dispositivos móviles o aplicaciones híbridas que funcionen en iOS, Android o Windows. Appium nació unos siete años más tarde que Selenium (2011 contra 2004), y por lo mismo su enfoque es más amplio y abarca el terreno móvil que Selenium por ahora deja de lado. También soporta múltiples lenguajes de programación, así como sistemas operativos como Unix, Windows, Linux o Mac OS. Por otro lado, Selenium provee la funcionalidad del testeo en paralelo, a diferencia de Appium.

Si te interesa conocer las principales diferencias entre ambas herramientas para elegir la correcta para tu proyecto, te recomiendo esta lista comparativa de Geeks for Geeks.

Fallar es bueno, si se hace con propósito y con gracia

Como profesionales de la tecnología estamos enfocado en el progreso y en el futuro. Esto implica innovación, que no es otra cosa que explorar caminos no andados con anterioridad. El precio a pagar es cometer errores y fracasar. Pero si lo hacemos inteligentemente, los fracasos pueden ser controlados, pequeños y poco costosos, así como provechosos en términos de aprendizaje.

Aceptar los fallos no es lo mismo que una liberación de responsabilidades. Al contrario, aceptarlos correctamente quiere decir hacernos responsables por los mismos, al grado de aprender a vivir con ellos y manejarlos como nos convenga.

Esta filosofía de las operaciones de desarrollo (DevOps) se debe llevar a cabo en por lo menos tres niveles: el de la cultura organizacional, las prácticas operativas y el uso de tecnologías automatizadas. Si se integra en estas tres áreas, haremos de nuestro trabajo una serie de “caídas hacia arriba”.