Command Line Heroes: segunda temporada: Equivócate mejor

Fail Better

13 de marzo de 2018

Desarrollo y distribución de aplicaciones.

Desarrollo profesional

Historia de la tecnología

Command Line Heroes • • Command Line Heroes: segunda temporada: Equivócate mejor

Command Line Heroes: segunda temporada: Equivócate mejor

About the episode

Las equivocaciones son el origen de los descubrimientos. Cuando empezamos algo nuevo, cometemos muchos errores. El secreto no es cometerlos rápido, sino cometerlos mejor.

En este episodio vemos que la tecnología acepta y aprovecha los errores. El abordarlos con curiosidad y franqueza es parte de nuestro proceso. Jennifer Petoff nos cuenta la forma en que Google ha desarrollado una cultura de aprendizaje y mejora a partir de ellos. Jessica Rudder nos explica que si cambiamos nuestra perspectiva y aceptamos los errores, podemos aprovecharlos y obtener éxitos inesperados. Y Jen Krieger nos habla de que los procesos ágiles nos ayudan a planificar las equivocaciones. Los errores no son el fin del mundo. De hecho, pueden ser el primer paso para lograr algo mejor.

Transcripción

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 es libre de reproches. La cosa no es buscar a quién culpar por lo que pasó, sino entender el sistema, entender lo que no funcionó en el sistema, comprender las lagunas del sistema que causaron o contribuyeron al incidente.

Libre de reproches. Me gusta esa expresión. Aquí la idea es que los errores son síntomas de problemas sistémicos, no se deben a que las personas son malas. Cuando pensamos en los errores de esa manera, es mucho más fácil aprender de ellos.

Y lo que queremos es una cultura en la que las personas se sientan seguras al admitir los errores y compartir los detalles de lo que salió mal, porque eso es lo que nos va a permitir aprender y mejorar como organización.

Una cultura psicológicamente segura. Jennifer señala que cuando las personas se sienten seguras de admitir errores, toda la organización puede aprender de ellos. Pero crear esa cultura requiere trabajo deliberado.

Una de las cosas que hacemos en Google es que realmente celebramos los errores. Tenemos premios para los análisis post mortem más valiosos. Tenemos una cultura donde contar historias sobre cosas que salieron mal es algo que se valora.

Celebrar los errores. Esa es una forma poderosa de cambiar la cultura. Cuando premias a las personas por compartir sus errores, estás enviando un mensaje claro de que los errores son oportunidades de aprendizaje, no motivos de vergüenza.

Pero hay algo más en la filosofía de Jennifer. No se trata solo de aceptar los errores cuando suceden, sino de diseñar sistemas que fallen de manera elegante.

Queremos que nuestros sistemas sean resilientes. Queremos que cuando algo salga mal - y algo siempre va a salir mal - el sistema pueda continuar funcionando, aunque sea de manera degradada.

Esta es una perspectiva fascinante: planificar para el fracaso. En lugar de tratar de crear sistemas perfectos que nunca fallen, crear sistemas que puedan manejar el fracaso elegantemente.

Y esto nos lleva a una lección más amplia sobre cómo los desarrolladores de código abierto han aprendido a trabajar con el fracaso. No se trata de evitarlo, sino de fallar mejor.

Para explorar esta idea más a fondo, hablé con Jessica Rudder, ingeniera de experiencias en GitHub y conductora del podcast CompChomp.

Una de las cosas que me encanta del desarrollo de software es que constantemente estás experimentando. Constantemente estás probando ideas nuevas, y muchas de esas ideas no van a funcionar.

Jessica ha visto esto de primera mano en GitHub, donde miles de desarrolladores experimentan con código abierto todos los días.

Lo que veo es que los desarrolladores más exitosos no son los que nunca cometen errores. Son los que aprenden rápidamente de sus errores y se adaptan.

Y esa capacidad de adaptación es especialmente importante en el código abierto, donde estás trabajando con personas de todo el mundo, con diferentes habilidades y perspectivas.

En el código abierto, tienes que ser humilde. Tienes que estar dispuesto a que otros vean tu código, lo critiquen, y sugieran mejoras. Eso puede ser intimidante al principio, pero es increíblemente valioso.

Esa humildad de la que habla Jessica es crucial. Cuando compartes tu código con el mundo, estás esencialmente invitando a otros a encontrar tus errores. Pero eso no es algo malo; es una oportunidad de aprender.

Algunos de mis mejores momentos de aprendizaje han venido de cuando alguien más miró mi código y dijo: "Hey, hay una manera mejor de hacer esto". Al principio puede picar un poco el ego, pero al final siempre termino siendo mejor desarrolladora.

Y esta es una de las grandes ventajas del código abierto: tienes acceso a una red global de mentores y revisores que pueden ayudarte a mejorar.

Pero Jessica también señala que no todos los errores son iguales. Hay una diferencia entre fallar rápido y fallar inteligentemente.

Fallar rápido está bien, pero lo que realmente quieres es fallar de manera informada. Quieres que tus experimentos estén bien diseñados para que puedas aprender lo máximo posible de cada intento.

Fallar de manera informada. Me gusta esa frase. Se trata de ser deliberado sobre cómo experimentas y qué esperas aprender de cada experimento.

Por ejemplo, si estás probando una nueva característica, no solo la lances y veas qué pasa. Piensa en qué métricas vas a medir, qué constituiría éxito, qué constituiría fracaso, y cómo vas a saber la diferencia.

Esta aproximación más sistemática al fracaso es algo que vemos mucho en el desarrollo moderno. Los equipos usan técnicas como pruebas A/B, despliegues canarios, y feature flags para experimentar de manera controlada.

Pero hay otro aspecto del fracaso que Jessica encuentra particularmente interesante: cómo los errores pueden llevar a descubrimientos inesperados.

Algunos de los proyectos más exitosos que conozco empezaron como algo completamente diferente. Los desarrolladores estaban tratando de resolver un problema, fallaron, pero en el proceso descubrieron algo aún más valioso.

Este tipo de serendipia es común en el código abierto. Un proyecto que empieza como una herramienta personal puede evolucionar hacia algo que beneficia a millones de usuarios.

Por eso creo que es importante no estar demasiado apegado a tu plan original. Tienes que estar dispuesto a pivotar cuando los datos te muestran que hay una mejor dirección.

Y esto nos lleva a una observación importante sobre la cultura del código abierto: es inherentemente experimental. Los desarrolladores están constantemente probando nuevas ideas, y el éxito a menudo viene después de muchos intentos fallidos.

Para entender mejor cómo esta cultura de experimentación se traduce en mejores prácticas de desarrollo, hablé con Jen Krieger, arquitecta principal de tecnología ágil en Red Hat.

Una de las cosas que me encanta de las metodologías ágiles es que están diseñadas para abrazar el cambio y el fracaso como parte del proceso.

Jen ha trabajado con equipos de desarrollo durante años, ayudándolos a adoptar prácticas que les permitan experimentar y fallar de manera más efectiva.

En el desarrollo tradicional en cascada, el fracaso era algo catastrófico. Si descubrías un problema fundamental después de meses de desarrollo, era un desastre. Pero con metodologías ágiles, descubres los problemas mucho más rápido, cuando aún es fácil y barato corregirlos.

Esta es una de las grandes innovaciones de las metodologías ágiles: acortar los ciclos de retroalimentación para que puedas fallar más rápido y más barato.

En lugar de esperar hasta el final del proyecto para mostrar tu trabajo a los usuarios, lo haces cada pocas semanas. En lugar de escribir todo el código antes de probarlo, escribes un poquito y lo pruebas inmediatamente.

Estos ciclos cortos de retroalimentación son fundamentales para aprender rápidamente de los errores. Cuanto más rápido puedas detectar un problema, más rápido puedes corregirlo.

Pero Jen también señala que adoptar esta mentalidad requiere un cambio cultural significativo.

Muchas organizaciones dicen que quieren ser ágiles, pero cuando algo sale mal, inmediatamente vuelven a buscar culpables. Tienes que estar realmente comprometido con la idea de que los errores son oportunidades de aprendizaje.

Y ese compromiso tiene que venir desde arriba. Los líderes tienen que modelar el comportamiento que quieren ver.

He visto equipos donde el líder admite abiertamente sus errores y habla sobre lo que aprendió de ellos. Esos equipos son mucho más innovadores y exitosos que los equipos donde todo el mundo tiene miedo de admitir que cometió un error.

Esta conexión entre seguridad psicológica e innovación es algo que la investigación ha confirmado una y otra vez. Los equipos donde las personas se sienten seguras de tomar riesgos son más creativos y productivos.

Pero Jen también ha observado cómo las prácticas ágiles han evolucionado para incorporar mejor las lecciones del código abierto.

Una de las cosas que hemos aprendido del código abierto es la importancia de hacer tu trabajo visible. Cuando tu código está en GitHub, cuando tus decisiones de diseño están documentadas, cuando tus errores están registrados en issues públicos, creas una cultura de transparencia.

Esa transparencia es poderosa porque permite que otros aprendan de tus errores sin tener que cometerlos ellos mismos.

En el código abierto, tus errores se convierten en recursos de aprendizaje para toda la comunidad. Alguien puede leer sobre un problema que tuviste y evitar caer en la misma trampa.

Y esto nos lleva de vuelta a una de las grandes fortalezas del código abierto: la capacidad de aprender colectivamente de los errores individuales.

Cuando un proyecto de código abierto encuentra un bug importante, no solo se soluciona el problema. Se documenta, se discute, y se convierte en conocimiento compartido para toda la comunidad.

Pero quizás lo más importante es que el código abierto ha normalizado la idea de que el software nunca está realmente "terminado". Siempre hay errores que corregir, características que mejorar, optimizaciones que hacer.

Y esa mentalidad de mejora continua es fundamental para fallar mejor. No se trata de crear algo perfecto desde el principio, sino de crear algo que pueda evolucionar y mejorar con el tiempo.

Jen tiene una observación interesante sobre cómo esta mentalidad ha cambiado la forma en que los desarrolladores ven su trabajo.

Antes, muchos desarrolladores veían su trabajo como crear productos terminados. Ahora, cada vez más desarrolladores ven su trabajo como crear sistemas vivos que van a evolucionar y cambiar constantemente.

Sistemas vivos. Me gusta esa metáfora. Implica que el software, como los organismos vivos, necesita adaptarse constantemente a su entorno para sobrevivir.

Y en ese contexto, los errores no son fallas del sistema, sino información sobre cómo el sistema necesita adaptarse.

Exactamente. Y cuando ves los errores de esa manera, se vuelven menos aterradores y más útiles. En lugar de algo que hay que evitar a toda costa, se convierten en datos que puedes usar para mejorar.

Esta perspectiva también cambia cómo los equipos planifican su trabajo. En lugar de tratar de predecir y prevenir todos los posibles problemas, planifican para poder responder rápidamente cuando surgen problemas inesperados.

Es como la diferencia entre construir un muro más alto para evitar inundaciones versus construir un sistema de drenaje mejor para manejar el agua cuando llegue. Ambos enfoques tienen su lugar, pero el segundo te da más flexibilidad.

Y Jen ha visto cómo esta flexibilidad se traduce en equipos más resilientes y adaptables.

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.

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.

Fail Better