La entrega de hoy es un especial dedicado a Kent Beck, una de las personas que sin duda, más ha influido en mi carrera. No me sorprendió en absoluto que tras leer Pensando en Sistemas y buscar quién del mundo del desarrollo de software estaba hablando de estos temas, lo primero que encontré fuera este proyecto suyo junto a Jessica Kerr: Systems Thinking for Developers.

🔄 Un bucle

El círculo vicioso de la burocracia

Era 2015, yo estaba demasiado ocupado aprendiendo toda la tecnología necesaria para escalar Audiense (entonces Socialbro). Además sacábamos features como churros porque con cada release conseguíamos noticias en los ProductHunt de la época —TechCrunch, Mashable— y esto nos enviaba miles de nuevos usuarios.

Lo de Agile me sonaba…, hacíamos “Scrum”. No tenía ni idea de la existencia de algo llamado eXtreme Programming ni mucho menos CI/CD. Estaba demasiado ocupado para pararme a buscarlo.

Por entonces una rama de código (feature branch) podía durar semanas y acumular miles de líneas modificadas en decenas de archivos. La revisión y aprobación de los pull requests tardaban varios días e implicaba que tanto la product manager hiciese QA (manual) y que se hiciese code review con todos los ciclos de iteraciones que conlleva detectar bugs o cosas a mejorar de la code review.

Nota que en el ejemplo de la imagen, soy yo quien hace merge de la rama. Y es que yo era «El Elegido», el único que desplegaba, y eso solo ocurría los miércoles. Por supuesto, lo suficientemente lejos del viernes como para que tuviéramos tiempo de subir hotfixes antes del fin de semana.

Nuestro proceso de despliegue consistía en yo cada miércoles preguntar en Slack: «voy a preparar deploy. algo por lo que esperar?»

Acto seguido integraba yo de todas las PRs que entrarían y hacía kun fu para desplegar con una larga lista de pasos manuales. Guardo con cariño esta camiseta con la que me sorprendió el equipo en uno de nuestros meetups.

La falta de confianza en nuestro código, la fragilidad de nuestro sistema y nuestras prácticas, nos llevaba en un círculo vicioso de burocracia que también afectaba a nuestra capacidad para salir del propio círculo.

Ya en 2016 Kent Beck alertaba de este efecto. Al leerlo casi una década después he visto reflejada la historia que os acabo de contar.

Aumentar la burocracia inicia un ciclo de retroalimentación positiva: menos se logra -> más presión -> más errores -> aún menos cambios por despliegue -> más burocracia -> menos se logra. Los esfuerzos aislados para reducir la burocracia aumentan la presión y aumentan la burocracia.

¿Cómo rompimos este círculo vicioso?

Abrazando los principios y prácticas de XP, Devops y Lean. Por citar algunos ejemplos:

• Haciendo el control de la calidad parte del flujo de valor y no un paso posterior.

• Producto, diseño y desarrollo son un mismo equipo y colaboran en todas las fases del ciclo de desarrollo del producto.

• Inversión en herramientas que reduzcan la carga cognitiva de los equipos: observabilidad, automatización de deploy, rollback, provisionamiento y gestión de infrastructuea, etc.

• Acortando los feedback loops: TDD, pequeños pasos, CI/CD, trunk-based development, continuous discovery, vertical slicing, etc.

• Fomentando una cultura de experimentación: blameless postmortems, retrospectivas, etc.

• Invirtiendo en la formación del equipo: formación en horario laboral, impulsada por la organización, tratada como una prioridad de primer nivel y no como un coste. Comenzando a educar el paladar sobre qué entendemos por calidad y qué significa hacer las cosas bien para nosotros.

🎛️ Un sistema

¿Qué sistema?

Si hay algo que aprender de lo anterior, no son las prácticas concretas que nos funcionaron en Audiense, sino la necesidad de entender el sistema. Estos sistemas socio técnicos normalmente trascienden el equipo de desarrollo y sus aspectos técnicos, e incluyen al resto de la organización, su cultura, procesos, clientes, mercado, etc. Algo tan alejado del aspecto técnico como generar los incentivos adecuados para cultivar una cultura de aprendizaje continuo fue lo que nos dio las herramientas para construir la nueva cultura de ingeniería de producto.

Esta breve reflexión de Kent Beck nos deja una lección muy importante. Aparentar que se acelera el trabajo acumulando tareas o recursos adicionales no necesariamente mejora el rendimiento del sistema principal. En su lugar, se crea un sistema paralelo para «aparentar» productividad sin cambiar el ritmo real de salida. Por eso, es fundamental entender qué sistema estamos optimizando realmente, y enfocar los esfuerzos en mejorar el sistema principal en lugar de satisfacer presiones externas sin efecto real en los resultados.

📖 Una cita

Coraje

Coraje es uno de los valores de XP más ignorados, quizás porque suele asociarse demasiado con emociones como la irritación, la rabia o la ira, que tienen una connotación más violenta en el enfrentamiento al miedo. Sin embargo, según la RAE, la primera acepción de coraje es: «Impetuosa decisión y esfuerzo del ánimo; valor».

A veces, el coraje se manifiesta como una inclinación a la acción. Si sabes cuál es el problema, haz algo al respecto. Otras veces, el coraje se manifiesta como paciencia. Si sabes que hay un problema, pero no sabes cuál es, se necesita coraje para esperar a que el verdadero problema se revele con claridad.

El coraje como valor principal, sin valores que lo contrapesen, es peligroso. Hacer algo sin tener en cuenta las consecuencias no es trabajo en equipo efectivo. Fomenta el trabajo en equipo buscando orientación en los otros valores sobre qué hacer cuando sientas miedo.

Si el coraje por sí solo es peligroso, en conjunto con otros valores es poderoso. El coraje de decir verdades, agradables o desagradables, fomenta la comunicación y la confianza. El coraje de descartar soluciones que no funcionan y buscar nuevas impulsa la simplicidad. El coraje de buscar respuestas reales y concretas genera retroalimentación.

— Kent Beck, Extreme Programming Explained: Embrace Change

Desplegar a producción un viernes, 1450 líneas de código con poca cobertura de tests, mediante un procedimiento manual tanto para el despliegue como para revertirlo, no es coraje, es temeridad. El coraje es lo que se necesita para cuestionar el status quo y buscar cambios más allá de lo que nos permite el código.

Esto es todo por hoy. Me encantaría que dejaras en los comentarios qué te ha parecido esta entrega y compartieras ideas sobre los temas que te gustaría ver en las próximas ediciones.

¡No olvides suscribirte para no perdértelas!