Fail Better

Si ya te sabes esta, me dices. Dos ingenieros están compilando su código. El ingeniero nuevo levanta las manos y grita: “¡Sí, se compiló mi código!" La ingeniera experimentada entrecierra los ojos y murmura: "Mmh. Se compiló mi código”.

Si ya llevas tiempo desarrollando, sabes que la percepción de los fracasos cambia. Hay problemas que antes te parecían imposibles de resolver, y que ahora ves como parte importante de una solución más grande. Lo que antes era un fracaso para ti, ahora te parece más como un logro en potencia.

Ya sabes que a veces tu código no se va a compilar. Ya sabes que vas a tener que jugar y experimentar a lo largo del camino, y vas a hacer cambios, a revisarlos y a rediseñarlos.

Esto es Command Line Heroes en español, un podcast original de Red Hat.

Ya sabemos que el lema de "equivocarse rápido" muchas veces se utiliza como una forma de alcanzar el éxito en menos tiempo. ¿Pero y si en lugar de decirles a los demás que se apresuren y se equivoquen rápido, los alentamos a que se equivoquen mejor?

La segunda temporada de Command Line Heroes en español se trata de la experiencia que se gana cuando se trabaja en el desarrollo, cómo nos hace sentir y cómo da resultados cuando vivimos en la línea de comando. Por eso dedicamos todo un episodio a lidiar con los fracasos, porque son esos momentos los que nos motivan a adaptarnos. El fracaso es una parte indispensable de la evolución, así que los desarrolladores de código abierto lo aprovechan al máximo. Claro que es mucho más fácil decirlo que hacerlo.

Imagínate que se descubre un nuevo soneto del mismísimo Shakespeare. De pronto se genera un gran interés en línea. Todo el mundo busca en Google. Pero entonces... Un pequeño defecto de diseño causa algo que se llama “agotamiento del descriptor de archivos”. Y crea un error en cascada. De repente, todo el tráfico empieza a circular en cada vez menos servidores. Muy pronto, la búsqueda de Shakespeare se satura, Google se cae y permanece así más de una hora.

Se perdieron 1200 millones de consultas de búsqueda. Se trata de una tragedia de proporciones shakesperianas, que sucede mientras los ingenieros de fiabilidad del sitio luchan por recuperarlo.

¿Y tú, Bruto? Entonces cae, César.

Bueno, perdón por interrumpirlos. Pero, el incidente de Shakespeare no sucedió. De hecho, es parte de una serie de ejemplos de desastres de un libro que se llama Ingeniería de fiabilidad de sitios. Y una de las grandes lecciones que aporta es que no hay que quedarse en el desastre nada más. Me refiero a esto.

En el caso de Shakespeare, la consulta de la muerte se resuelve enviando el tráfico a un clúster único, que se sacrifica. Eso le da al equipo tiempo suficiente para agregar más capacidad. Pero no pueden quedarse en eso. Por muy terrible que fuera el problema, no solo deben concentrarse en resolverlo. Porque los errores no tienen por qué terminar en sufrimiento, sino que pueden enseñarnos mucho.

Hola. Soy Jennifer Petoff.

Jennifer trabaja en Google. Es gerente sénior de programas del departamento de Ingeniería de fiabilidad de los sitios (SRE, por sus siglas en inglés), dirige el programa de educación global de dicho departamento, y también es una de las autoras de ese libro, el que describe el ejemplo de Shakespeare. Jennifer cree que para mejorar las cosas es necesario profundizar en ese tipo de desastres. Pero solo si tu cultura te permite aprovechar los errores y las sorpresas.

Así que, vamos al caos de Shakespeare otra vez. Hay una solución directa. Si rechazamos la carga, podemos evitar el error en cascada. Pero el trabajo real comienza cuando las cosas vuelven a la normalidad. El trabajo real está en el análisis post mortem.

Después de resolver el incidente, se crea un análisis post mortem. En Google se realiza un análisis post mortem de todos los incidentes, y se diseñan las medidas correspondientes para prevenirlos, pero también para detectar y reducir de manera más efectiva los incidentes similares o toda esa categoría de problemas en el futuro.

Y ahí llegamos a uno de los puntos fundamentales: No se trata solo de resolver ese incidente en particular, sino de ver lo que dice sobre ese tipo de problemas. Los análisis post mortem, los que realmente sirven, no solo nos dicen lo que salió mal el día anterior, sino que nos brindan información sobre el trabajo que hacemos hoy y sobre lo que planificamos para el mañana. Entonces, ese tipo de pensamiento más amplio cambia la perspectiva que tenemos de los accidentes y los errores, y nos infunde respeto por ellos porque los convierte en una parte indispensable de la vida laboral diaria.

Así que un buen análisis post mortem no solo aborda el problema en cuestión, sino que abarca toda la categoría de problemas. El objetivo es ubicar lo que salió bien, lo que salió mal, lo que sucedió por suerte y las medidas priorizadas que podemos tomar para garantizar que no vuelva a suceder. Porque si no tomas medidas, la historia está destinada a repetirse.

En Google hay un enfoque en los análisis post mortem sin culpas, y eso marca la diferencia. Si no le echamos la culpa a nadie cuando algo sale mal, entonces realmente podemos profundizar en los errores de manera honesta, para aprender de ellos sin esconder información ni discutir. Los análisis post mortem sin culpas se han convertido en una parte esencial de la cultura en Google, y el resultado es un lugar de trabajo donde no se le tiene miedo al error. Está normalizado.

¿Cómo ve Google los errores? El que todo sea perfecto el 100 % del tiempo es un objetivo imposible, o sea, si crees que eso se puede lograr, te estás engañando. Va a haber errores, pero hay que saber cuándo y cómo van a suceder. En Google los errores se celebran, así que son algo de lo que podemos aprender, y los análisis post mortem se distribuyen ampliamente entre los equipos para garantizar que ese aprendizaje esté totalmente disponible.

Los errores son inevitables, pero no hay que equivocarse dos veces del mismo modo. Errar es humano, pero hay que evitar repetir el error.

Bueno, el comercial de 1984 tuvo mucho riesgo. De hecho, era tan riesgoso que Apple no quería lanzarlo cuando lo vio. Probablemente has oído historias de que a Steve le gustó, pero a la junta de Apple no mucho. De hecho, estaban tan enfadados de que se hubiera gastado tanto dinero en ello que querían despedir a la agencia publicitaria. Steve fue el que defendió a la agencia.

Abordas la situación inmediatamente, pero luego te tomas el tiempo de escribir lo que sucedió para que los demás puedan aprender también. En todos los incidentes hay que pagar un precio, pero si no escribes un análisis post mortem para aprender de esa experiencia, no vas a recuperar ese costo, y creo que esa es la lección fundamental. En Google creemos firmemente en una cultura sin culpas. No se gana nada señalando a las personas; de hecho, si les echas la culpa van a intentar esconder el error, que de todos modos va a suceder.

Es muy importante recordar algo que Jennifer dijo antes, que el trabajo sin errores es una fantasía. Siempre hay algo que va a salir mal. Pero entonces hay que cambiar nuestra forma de pensar. Hay que desechar la idea de que hay un solo objetivo final y definible, donde todo saldrá como nos lo imaginamos. No hay una meta única a la que queramos llegar, y resulta que eso es algo muy positivo y con un gran potencial.

El esfuerzo de Google por aceptar los errores tiene mucho sentido. Es muy práctico. ¿Pero hay ejemplos concretos de errores que realmente hayan mejorado las cosas, o es para hacernos sentir mejor cuando hemos intentando compilar algo 200 veces?

Bueno, pues hay alguien que puede contestar esa pregunta.

Me llamo Jessica Rudder. Soy ingeniera de software en GitHub.

Jessica ha tenido su buena dosis de errores en GitHub. En cierto sentido es un campo para el fracaso, y con el tiempo ha reunido algunas anécdotas de los momentos en que el fracaso le abrió la puerta al éxito rotundo. Aquí hay un ejemplo:

En la década de los 90, había una empresa de desarrollo de juegos que estaba trabajando en un juego completamente nuevo. Básicamente, era un juego de carreras, pero la diferencia es que iba a ser de carreras callejeras. Pero no solo compiten en las carreras con los demás, sino que también hay PNJ (personajes no jugadores), que son patrullas que los persiguen. Si te agarra una patrulla, se supone que te tienes que detener y entonces pierdes la carrera. Así que arman todo el código, comienzan a ejecutarlo y de pronto descubren que calibraron completamente mal el algoritmo, y en lugar de que las patrullas persiguieran los vehículos de los jugadores, simplemente salían de las calles laterales y les chocaban muy fuerte.

Fue un desastre total. Y en lugar de ponerse nerviosos, pensaron: “Vamos a seguir adelante para ver si a la gente le gusta, y así vamos a saber qué modificar del algoritmo”. Así que lo enviaron a los probadores de juegos, y descubrieron que se divertían mucho más escapando de los policías y tratando de evitar que los capturaran esas patrullas violentas y malvadas, de lo que se habrían divertido con el juego de carreras en sí. De hecho, fue tan divertido que el equipo de desarrollo cambió todo el concepto con el que estaban desarrollando el juego.

¿Ya adivinaste de qué estamos hablando?

Sí, así es como terminamos con Grand Theft Auto. O sea, es la franquicia de videojuegos más vendida de todos los tiempos, y si existe es gracias a que cuando descubrieron que se habían equivocado con el algoritmo, pensaron: “Bueno, pues vamos a probarlo”. “Vamos a ver qué tenemos y qué podemos aprender”.

Increíble, ¿verdad? Pero este es el secreto: Cuando el equipo de Grand Theft Auto se enteró del error, tuvo que abrir las orejas y disponerse a escuchar. Tenían que seguir siendo curiosos.

Si los desarrolladores no hubieran tenido la mente abierta y no hubieran decidido ver qué podían aprender del error, nunca habríamos disfrutado Grand Theft Auto. Habríamos tenido un juego de carreras callejeras aburrido y del montón.

Vamos a seguir con los videojuegos un rato; algo parecido sucedió con Silent Hill. Era un juego triple A enorme, una producción a gran escala. Pero tenían problemas graves con los elementos emergentes. Ciertas partes del paisaje no se procesaban lo suficientemente rápido, así que de repente aparecía una pared o una parte de camino que salía de la nada. Fue un problema determinante que los atrasó en el ciclo de desarrollo. Pero entonces, ¿qué podían hacer? ¿Tirar todo a la basura? ¿Darse por vencidos? ¿O aprovechar el problema?

Lo que hicieron fue llenar todo de una niebla muy densa y escalofriante. Porque resulta que es muy fácil de producir para los procesadores, y no causa ningún tipo de retraso. Pero además evita que veas las cosas a distancia, así que los edificios seguían ahí, pero ya no podías verlos porque la niebla los tapaba. Entonces, cuando entran en escena, ya están allí y parece que salen de la niebla.

De hecho, todo el mundo terminó adorándola, y hasta se le considera otro personaje de la franquicia de Silent Hill. Hace que el juego dé más miedo porque limita la visión del jugador. Y aunque los procesadores lograron tal velocidad que ya no era necesario cubrir los elementos emergentes, ¡dejaron la niebla!

Porque ya no se puede pensar en un juego de Silent Hill sin niebla. Y lo único que hacía era tapar un error.

Para salvar un desarrollo tan importante, aceptaron el error en lugar de huirle. Y ese lema de no temerle al fracaso no solo se aplica a las decisiones empresariales, sino también a los pequeños detalles. Observar el fracaso con calma y de frente es la forma en que mejoramos, poco a poco.

Muchas veces la gente se queda atrapada en el problema y concluye que un error implica que es mala en x o y. No es: “Uf, este código no funciona y todavía no sé cómo arreglarlo”. Sino: “No sé cómo escribir con JavaScript”. Si dices: “No sé cómo escribir con JavaScript”, nunca vas a aprender lo que necesitas saber. Pero si eres capaz de identificar el problema: "Uy, no sé cómo hacer que este bucle funcione en JavaScript", entonces ya sabes lo que necesitas buscar en Google para encontrar la respuesta y lograr que funcione perfectamente. O sea, va a haber dificultades, pero menos.

Nuestros errores nos impulsan a lograr cosas más importantes; los experimentos, los fracasos, los intentos valientes forman la mayor parte de la aventura, ya sea que empieces tus desarrollos o seas director de un estudio importante. Esto es muy cierto en las comunidades de código abierto. Los errores pueden ser maravillosos en el código abierto, y hacia allá se dirige nuestra historia.

Ya vimos cómo las buenas equivocaciones pueden darnos buenas sorpresas y enseñarnos cosas que ni siquiera sabíamos que queríamos intentar. Y en el mejor de los casos, eso sucede con la cultura de desarrollo del código abierto: no castiga los errores, los convierte en algo positivo. Y para comprender cómo la apertura al fracaso se convierte en desarrollo de código abierto, hablamos con Jen Krieger. Es la arquitecta principal de la tecnología ágil de Red Hat. Hablamos sobre las actitudes hacia el fracaso en el código abierto y cómo definen lo que es posible. Escucha:

El lema de “equivocarse rápido y descomponer las cosas” es casi como un grito de guerra para nuestra comunidad. ¿Tú qué opinas?

Bueno, varias cosas.

Continúa.

Equivócate rápido, hacia delante y rápidamente, todo eso. Pero para darte el contexto, al principio de mi carrera, trabajaba en una empresa donde no se admitían los errores. Si te equivocabas, se caía la única aplicación. En serio, no podías hacer nada mal, no había espacio para equivocarse. Y eso realmente te estresa. O sea, la idea de que no puede uno equivocarse nos llevó a un movimiento casi cultural, por así decirlo, que luego se convirtió en las maravillosas palabras “ágil” y “DevOps”. Cuando veo esas palabras, lo que veo es que simplemente les pedimos a los equipos que hagan una serie de experimentos muy pequeños que los van a ayudar a corregir los errores sobre la marcha.

La idea es: “Ah, tomaste una decisión, muy bien”. A lo mejor tomaste una decisión arriesgada que tal vez salga bien porque era la correcta. O al contrario, tal vez te equivocaste y ahora ya sabes que esa no era la dirección correcta.

Sí, suena lógico. Entonces cuando piensas en “equivocarse rápido y descomponer las cosas” en ese aspecto, ves que hay cierta estructura, e incluso hay mejores prácticas para equivocarse, para hacerlo bien. Dinos algunas de las mejores prácticas y principios que nos expliquen cómo equivocarnos de una manera que resulte bien al final.

Siempre les digo a los ingenieros que tienen que descomponer el desarrollo lo antes y lo más frecuentemente posible. Porque si lo descomponen y lo saben, tienen la oportunidad de arreglarlo en el momento. Entonces todo tiene que ver con el concepto de los ciclos de retroalimentación, y con asegurar que los que tienes en tu trabajo sean lo más cortos posible.

Entonces, en el desarrollo de código abierto, yo mando un parche, y alguien contesta: “No lo acepto por estos nueve motivos” o “Está perfecto, adelante”. O podrías enviar un parche y que un bot te diga que no funcionó porque no se diseñó correctamente. Hay todo tipo de retroalimentación.

Y luego, en el desarrollo de código abierto, es posible que también haya ciclos de retroalimentación más largos en los que dices: “Quiero diseñar esta nueva función, pero no estoy seguro de todas las reglas. ¿Hay alguien que me ayude a diseñarlas?”. Así que empiezas un largo proceso donde sostienes conversaciones largas y detalladas en las que la gente participa y se le ocurre la mejor idea.

Hay muchos ciclos de retroalimentación diferentes que pueden ayudarte.

Jen cree que esos ciclos de retroalimentación pueden ser diferentes en cada empresa. Se pueden personalizar y pueden funcionar de muchas maneras distintas. Pero lo importante es que ni siquiera los llama equivocaciones o errores. Simplemente les dice “ciclos de retroalimentación”. Es un sistema orgánico. Una manera muy saludable de pensar en todo el proceso.

Pero hay una actitud hacia esos pequeños problemas que tiene un efecto completamente opuesto.

Hay empresas que hacen exactamente lo que no se debe hacer.

Ajá (afirmativo).

Si los directivos o el nivel más alto de la empresa piensan en avergonzar a las personas por hacer algo mal o quieren infundir miedo en relación con los resultados de desempeño, se siente como: “Si no haces un buen trabajo, no obtendrás los bonos” o “Si no haces un buen trabajo, te voy a poner en un plan de desempeño”. Ese es el tipo de cosas que generan hostilidad.

Lo que ella describe allí es que hay un error con los errores. Se equivocan porque no aprovechan los errores. Y es lo mismo que la actitud de Jennifer Petoff, ¿verdad? ¿Te acuerdas de la idea de los análisis post mortem sin culpas que escuchamos al comienzo del episodio?

Sí, es muy interesante. O sea, si somos un poco más estrictos en nuestra manera de trabajar juntos, o tal vez más conscientes y más decididos en nuestra forma de trabajar juntos, casi vamos a estar obligados a ser mejores ante nuestros propios errores.

Sí. Hay empresas que ya lo saben, y lo aprendieron hace mucho, y Toyota es el ejemplo perfecto de una empresa que adoptó el concepto de aprendizaje y mejora continuos de una manera que rara vez veo en las empresas. La idea es que cualquier persona en cualquier momento puede indicar que algo no funciona correctamente. No importa quién sea, ni en qué nivel de la empresa se encuentre. En su cultura, simplemente se entiende que está bien. Y yo diría que ese entorno de aprendizaje y mejora constantes es una de las prácticas líderes, una de las cosas que yo esperaría de una empresa para poder dar lugar a los errores y permitir que ocurran.

Ajá (afirmativo). Sí.

Si preguntas por qué las cosas no funcionan bien en lugar de buscar culpables, esconder errores, o culpar a los demás, la situación es completamente diferente. Cambia la conversación.

Y es interesante porque mencionaste anteriormente que el lema de descomponer las cosas, de “equivocarse rápido y descomponer cosas” era una cultura donde se rechazaba la forma en que se hacían las cosas. Pero parece que ese lema también ha generado una forma diferente en que trabajan los equipos dentro de una empresa, dentro de un equipo tecnológico. Cuéntame un poco más de eso. Cómo ha cambiado la forma en que los desarrolladores ven sus funciones y cómo interactúan con otras personas de la empresa.

Cuando empecé a trabajar con ingenieros, todos se sentaban en un área pequeña. Y hablaban entre ellos. No convivían realmente con nadie del personal comercial. No entendían ninguna de las solicitudes que les llegaban, y pasamos mucho tiempo intentando entender qué necesitaban ellos para lograr el éxito, en lugar de pensar en lo que necesitaba la empresa para poder hacer su trabajo. Entonces, era: “Soy ingeniero, ¿qué necesito para codificar esta función?”. Lo que observo hoy en casi todos los equipos con los que trabajo es que la conversación ha cambiado significativamente de: “¿Qué necesito como ingeniero para hacer mi trabajo?” a “¿Qué es lo que el cliente o el usuario necesitan para sentir que la función que estoy haciendo les sirve? ¿Cómo usan el producto? ¿Qué puedo hacer para facilitarles la vida?”.

Muchas de esas conversaciones han cambiado, y creo que por eso las empresas están mejorando y distribuyen buena tecnología. También creo que mientras más rápido lleguemos al lanzamiento, más rápido sabremos si tomamos buenas decisiones y si nuestras suposiciones eran correctas. Si hacemos una suposición sobre lo que el usuario podría desear, antes teníamos que esperar de uno a dos años para saber si teníamos razón o no.

Pero en la actualidad, si pensamos en el modelo de un Amazon o Netflix, veremos que publican sus suposiciones sobre lo que los clientes quieren cientos de veces al día. Y la respuesta que reciben de la gente que usa las aplicaciones les dice si están haciendo lo que los usuarios necesitan o no.

Sí, y pareciera que se necesita más cooperación, porque incluso el consejo que diste antes sobre hacer los desarrollos, descomponerlos y descomponerlos seguido. Eso como que requiere que el equipo de ingeniería o los desarrolladores estén más a la par con DevOps, ¿no?, para descomponer los desarrollos y ver cómo se ven, para poder sacar las versiones antes y con frecuencia. Pareciera que se necesita más cooperación entre los dos.

Sí, y es gracioso para alguien que tiene el título de “agile coach” o en mi caso, arquitecta principal de tecnología ágil, porque la intención original del Manifiesto de la Tecnología Ágil es que la gente cambie su manera de pensar respecto a esas cosas. “Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros”. Es realmente lo principal, lo fundamental... Es la raíz de lo que supuestamente debe hacer la tecnología ágil. Y si nos adelantamos 10, 15 años o más, hasta la llegada de DevOps y la insistencia de que tengamos integración e implementación continuas, entonces empezamos a ver cómo ayuda la supervisión de los demás, comenzamos a pensar de manera diferente sobre cómo pasar el código al otro lado del muro.

Y eso es lo que teníamos que pensar cuando empezamos a hablar de la tecnología ágil.

Ajá (afirmativo). Absolutamente. Entonces, independientemente de la manera en que las personas apliquen esa idea de los errores, podemos estar de acuerdo en que aceptarlos y normalizarlos es solo parte del proceso, es algo que debemos hacer, algo que simplemente sucede y que podemos manejar, que tal vez podemos hacer “de la manera correcta”; eso es bueno. Ha ayudado al código abierto. Cuéntanos algunos beneficios de este nuevo movimiento, esta nueva cultura de aceptar los errores como parte del proceso.

Pues ver el proceso es maravilloso. El tener la oportunidad de ver que las personas pasan de estar en una situación en la que tienen miedo de lo que puede suceder, a una situación en la que pueden hacer distintos intentos y crecer, para ver cuál podría ser la respuesta correcta... De verdad es fantástico ver eso. Es como si florecieran. Se vuelven más seguros de sí mismos, se dan cuenta de que pueden hacerse cargo de lo que son. Pueden tomar decisiones por ellos mismos, no tienen que esperar a que nadie lo haga.

Ver los fracasos como libertad. Uy, ¡me encanta! Jen Krieger es la arquitecta principal de la tecnología ágil de Red Hat.

No todos los proyectos de código abierto alcanzan la fama y el éxito de los grandes, como Rails o Django, o Kubernetes. De hecho, casi ninguno llega a eso. La mayoría son proyectos más pequeños con un solo colaborador. Proyectos especializados que resuelven pequeños problemas que enfrenta un pequeño grupo de desarrolladores, o que quedaron abandonados y ya no se los ha vuelto a tocar en años. Pero que todavía pueden aportar mucho. De hecho, muchos de esos proyectos siguen siendo sumamente útiles, porque otros proyectos los reciclan, los supraciclan y los absorben.

Y otros simplemente nos inspiran y nos enseñan de sus errores. Porque los fracasos, en un ámbito saludable y de código abierto, nos dan algo mejor que una victoria. Nos dan una perspectiva. Y hay otra cosa. A pesar de todos esos callejones sin salida, a pesar de todos los riesgos que corremos con los desarrollos, la cantidad de proyectos de código abierto se duplica cada año; nuestra comunidad está prosperando, y no estamos prosperando a pesar de nuestros fracasos, estamos prosperando gracias a ellos. En el siguiente episodio: cómo cambia la seguridad en un mundo DevOps. La implementación constante significa que la seguridad avanza en cada etapa del desarrollo, y eso cambia la forma en que trabajamos.

Command Line Heroes en español es un podcast original de Red Hat. Escúchalo gratis en Spotify, Apple Podcasts, Google Podcasts o donde quieras. Hasta la próxima. Sigan programando.