Fail Better

Escucha este episodio más tarde

trophy

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.

00:00 - Presentadora

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”.

00:18 - Presentadora

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.

00:37 - Presentadora

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.

Presentadora

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?

01:20 - Presentadora

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.

01:59 - Presentadora

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.

02:33 - Presentadora

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.

02:45 - Actor

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

02:54 - Presentadora

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.

03:13 - Presentadora

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.

03:38 - Jennifer Petoff

Hola. Soy Jennifer Petoff.

03:41 - Presentadora

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.

04:08 - Presentadora

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.

04:25 - Jennifer Petoff

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.

04:42 - Presentadora

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.

05:12 - Jennifer Petoff

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.

05:32 - Presentadora

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.

06:01 - Jennifer Petoff

¿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.

06:23 - Jennifer Petoff

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

06:34 - Presentadora

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.

06:50 - Jennifer Petoff

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.

07:27 - Presentadora

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?

08:26 - Presentadora

Bueno, pues hay alguien que puede contestar esa pregunta.

08:29 - Jessica Rudder

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

08:33 - Presentadora

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:

08:50 - Jessica Rudder

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.

09:37 - Jessica Rudder

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.

10:17 - Presentadora

¿Ya adivinaste de qué estamos hablando?

10:21 - Jessica Rudder

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”.

10:41 - Presentadora

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.

10:52 - Jessica Rudder

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.

11:07 - Presentadora

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?

11:42 - Jessica Rudder

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.

12:15 - Presentadora

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!

12:33 - Jessica Rudder

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

12:40 - Presentadora

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.

13:01 - Jessica Rudder

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.

13:36 - Presentadora

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.

14:14 - Presentadora

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:

14:47 - Presentadora

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

15:04 - Jen Krieger

Bueno, varias cosas.

15:06 - Presentadora

Continúa.

15:06 - Jen Krieger

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.

16:02 - Jen Krieger

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.

16:18 - Presentadora

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.

16:44 - Jen Krieger

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.

17:08 - Jen Krieger

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.

17:25 - Jen Krieger

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.

17:45 - Jen Krieger

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

17:50 - Presentadora

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.

18:11 - Presentadora

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

18:18 - Jen Krieger

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

18:23 - Presentadora

Ajá (afirmativo).

18:24 - Jen Krieger

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.

18:50 - Presentadora

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?

19:07 - Presentadora

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.

19:23 - Jen Krieger

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.

20:06 - Presentadora

Ajá (afirmativo). Sí.

20:07 - Jen Krieger

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.

20:23 - Presentadora

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.

20:55 - Jen Krieger

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?”.

21:56 - Jen Krieger

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.

22:25 - Jen Krieger

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.

22:46 - Presentadora

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.

23:15 - Jen Krieger

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.

23:56 - Jen Krieger

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

24:03 - Presentadora

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.

24:36 - Jen Krieger

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.

25:05 - Presentadora

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

25:19 - Presentadora

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.

25:54 - Presentadora

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.

26:54 - Presentadora

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.

Command Line Heroes logo

Sobre el podcast

Command Line Heroes en español cuenta las épicas historias reales de cómo los desarrolladores, programadores, hackers, geeks y rebeldes de código abierto están revolucionando el panorama tecnológico. Presentado por Red Hat, este podcast se basa en el galardonado programa en inglés del mismo nombre.

Presentado por Red Hat

Durante 25 años, Red Hat ha llevado tecnologías de código abierto a la empresa. Desde el sistema operativo hasta los contenedores, creemos en la construcción conjunta de una mejor tecnología y celebramos a los héroes anónimos que están reinventando nuestro mundo desde la línea de comandos.