Sunday, September 12, 2021

Good talks/podcasts (September 2021 II)



These are the best podcast/talks I've seen/listen to recently:

  • Chapter Two with Christina Wodtke, Author of Radical Focus (Christina Wodtke, Barry O'Reilly) [Company Culture, Culture, Engineering Culture, Inspirational] [Duration: 0:31:00] A great discussion to understand how to correctly introduce and use OKRs.
  • Day Two Cloud 111: Infrastructure As Software With Kris Nóva (Kris Nóva) [Cloud, Devops, Infrastructure, Platform, Platform as a product] [Duration: 0:53:00] thought-provoking podcast episode. Kris Nóva, claims that managing infrastructure using tools like Terraform isn’t that far away from just writing your own code to do the job yourself.
  • Rails Conf 2013 The Magic Tricks of Testing (Sandi Metz) [Agile, Technical Practices, XP, testing] [Duration: 0:32:00] (⭐⭐⭐⭐⭐) This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn't magic, it's a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.
  • Honeycomb's secret to high-performing teams (Charity Majors) [Continuous Delivery, Engineering Culture, Operations, Technical leadership] [Duration: 0:51:00] (⭐⭐⭐⭐⭐) Interesting conversation about high performance engineering organizations and how the pace of production is the heartbeat of the organization. They also discuss some very interesting ideas about how great teams generate great engineers, rather than the other way around.
  • Why There are Now So Many Shortages (It's Not COVID) [General, Lean] [Duration: 0:20:00] Interesting documentary on the impact on supply chains of the pandemic and how in many cases trying to use (without following the principles) lean ideas has generated fragility and lack of adaptability.
  • Software Engineering podcast: Episode 473: Mike Del Balso on Feature Stores (Mike Del Balso) [Data Engineering, Data Science, Machine Learning] [Duration: 0:55:00] (⭐⭐⭐⭐⭐) Mike Del Balso co-founder of Tecton discusses Feature Stores and how it helps operationalize Machine Learning.
  • WTF is Platform as a Product? (Matthew Skelton) [Devex, Platform, Platform as a product, team topologies] [Duration: 1:28:00] Matthew explains why the platform-as-product approach can be a game-changer for organisations building and running software-enabled products and services. Using ideas and patterns from Team Topologies—including Thinnest Viable Platform, team cognitive load, and the evolutionary team interaction modes—he explains how organisations like Adidas and Uswitch have successfully used the platform-as-product model to accelerate and simplify the delivery of software at scale.
Reminder, All these talks are interesting even just listening to them, without seeing them.

Related: 

Sunday, September 05, 2021

Good talks/podcasts (September 2021 I)

 


These are the best podcast/talks I've seen/listen to recently:

  • Platform Engineering as a (Community) Service (Nicki Watt) [Devex, Platform, Platform as a product] [Duration: 0:39:00] Interesting talk about what is platform engineering, how to create a great developer experience.
  • Principles Of Microservices (Sam Newman) [Architecture, Architecture patterns, DDD, Microservices] [Duration: 0:56:00] This talk describe the microservices principles (modeled around business domain, a culture of automation, hide Implementation details, decentralize, deploy Independently, isolate failure, highly observable, etc).
  • Platform as a Product: How to Delight Your Developers and Deliver Value for Your Customers (Paula Kennedy, Colin Humphreys) [Architecture, Devex, Platform, Platform as a product] [Duration: 0:57:00] In this talk, Paula and Colin will provide detailed, practical steps on how to form a successful platform team, how to apply the Build-Measure-Learn feedback loop to your internal platform, and how to engage your application developers and delight them. By creating and operating a platform that meets their needs, your developers can focus on what's most important for them: delivering their products, delighting their customers, and driving business value.
  • Real Example of a Deployment Pipeline in the Fintech Industry (Dave Farley) [Continuous Delivery, Devex, Platform] [Duration: 0:18:00] Dave Farley shows a real deployment pipeline in-use in a Fintech company called TransFICC based in London. TransFICC adopted Continuous Delivery from the start and practice it at an advanced level. Delivering frequent, changes into production in a complex system, working in a regulated industry.
  • How To Build Quality Software Fast (Dave Farley) [Continuous Delivery, Engineering Culture] [Duration: 0:15:00] (⭐⭐⭐⭐⭐) In this episode, Dave Farley explores how we can move fast with high quality and how one reinforces the other. Speed and quality are both hallmarks of a Continuous Delivery approach and best practices for building great software.
  • Making developer effectiveness a reality (Rebecca Parsons, Tim Cochran, Keyur Govande, Pia Nilsson) [Devex, Platform as a product] [Duration: 0:41:00] There’s often lots of talk about how companies can make their developers more productive. But it may be more useful to think about developer effectiveness: how to ensure they’re building the most useful products for their customers. This is about providing an environment that allows developers to be effective. Our special guests from Spotify and Etsy give us their unique perspectives.
  • Small batches podcast: The Toyota Way (Adam Hawkins) [Lean] [Duration: 0:08:00] (⭐⭐⭐⭐⭐) A summary of 14 principles described in Jeffery Liker's 2021 book "The Toyota Way".
  • WorkLife podcast: Why it Pays to Raise Pay (Adam Grant) [Company Culture, Culture, Inspirational, Management] [Duration: 0:44:00] When employees are paid more, they give more. Going above market pay might sound like a fantasy, but in a growing number of companies it’s becoming a profitable reality. Peek inside workplaces that have reinvented their pay structures to give employees their worth and more—and explore the science of how it can pay off for everyone in the long run.
Reminder, All these talks are interesting even just listening to them, without seeing them.

Related: 

Saturday, August 14, 2021

Good talks/podcasts (August 2021 I)


 

These are the best podcast/talks I've seen/listen to recently:

  • Top Software Engineering Interview Tips (Dave Farley) [Engineering Culture, professionalism] [Duration: 0:15:00] In this episode, Dave Farley, of Continuous Delivery, talks about his experience of technical interviews. Dave has conducted hundreds of software engineer job interviews and has some thoughts on how we could do better as both interviewers and as interviewees.
  • The reality of testing in an artificial world (Angie Jones) [AI, testing] [Duration: 0:27:00] Inspirational (and funny) talk about how to approach testing in a system using AI.
  • Theory of Constraints 3 Bottle Demo to improve Flow (Arrie van Niekerk) [Lean, TOC] [Duration: 0:06:00] This demo shows the strategies for dramatically improving flow using Theory of Constraints, using an experiment with a glass bottle to show the potential improvements that can be unlocked if the right strategy is applied at the bottleneck.
  • Output vs. Outcome & Impact (Jeff Patton) [Lean Product Management, Product, Product Discovery] [Duration: 0:10:00] Product thinking moves our focus from fast output to outcome and impact. This video is a great summary of this thinking.
  • One Step At A Time (Jason Gorman) [Technical Practices, XP, tdd] [Duration: 0:12:00] (⭐⭐⭐⭐⭐) Jason Gorman explains why focusing on one problem at a time is such a valuable habit for a software developer, and why the quickest route is usually the safest one
  • Reduce Alerting Noise with One Weird Trick (Liz Fong-Jones) [Observability, Technical Practices] [Duration: 0:10:00] (⭐⭐⭐⭐⭐) A great and concise description of SLI/SLOs and how to use them to improve our lives.
  • Domain Driven Design with BDD (Dave Farley) [DDD, Technical Practices, XP, tdd] [Duration: 0:16:00] Dave Farley explores how we can use this behavioural focus as a tool to better structure our software development and software engineering approach. How it can enhance our understanding, bridge gaps between different groups of people in the development process, better structure our development activities to focus more on the outcomes that we are aiming for and make the whole thing more testable.
  • GeePaw Hill "More Smaller Steps" (GeePaw Hill) [Agile, Lean Software Development, Small Safe Steps (3s), XP] [Duration: 1:20:00] (⭐⭐⭐⭐⭐) A great talk for anyone trying to do lean/agile software development. Explain why we need to give small safe steps (3s). Very interesting Q&A session at the end.
Reminder, All these talks are interesting even just listening to them, without seeing them.

Related: 

Saturday, August 07, 2021

Revisiones de código (Síncronas y Asíncronas)

Actualización 30/8/2021: 
Ampliada seccion "Visión de la industria y personal" y añadida referencias adicionales.


¿Qué es una Code Review?

Aunque existen distintos tipos y con distintos objetivos en este articulo nos vamos a referir como Code Review a aquellas revisiones de un cambio de codigo/configuracion/esquema BD que solicitamos que nos haga otro compañero antes de incorporar el cambio en el repositorio común de código. El objetivo de estás revisiones es controlar la calidad e intentar evitar que se introduccan errores en el repositorio común de código y por tanto evitar que el cambio salga a producción.

Por tanto las code review de las que hablamos:

  • Intentan evitar errores/bugs actuando como salvaguarda.
  • Se producen dentro del flujo para llevar cualquier cambio a producción.

Existen otros tipos de code review que no se hacen en el flujo normal de desarrollo y que suelen usarse para aprendizaje compartido del equipo. En este articulo no las vamos a tratar.

Lo más común: las Code reviews asíncronas

En este contexto, una forma muy común (y para algunos recomendada) de realizar las code reviews, consiste en que un desarrollador (A) trabaja de forma individual en una tarea (d) y al terminar el cambio general una Pull Request / Merge Request que otra persona del equipo debe revisar asíncronamente.

Podemos ver un ejemplo de esta forma de trabajar en el siguiente diagrama. En él se puede ver como el desarrollador A genera PR/MRs que el desarrollador B revisa, generando propuestas de cambios que el desarrollador A deberá incorporar.

En el ejemplo, el desarrollo a realizar está compuesto por los incrementos d1, d2, d3, y vemos como es desplegado a producción al finalizar el la code review del incremento d3.


Podemos ver que el flujo de desarrollo de A se interrumpe constantemente para esperar el feedback correspondiente a cada code review. Esto hace que el tiempo total que pasa hasta que hacemos una release a producción y conseguir feedback de verdad es muy largo.

Con esta forma de trabajar, es probable que inconscientemente exista la tendencia a trabajar en incrementos más grandes, para evitar la espera por la code review. De hecho, esta tendencia a hacer pasos más grandes es lo que me he encontrado en muchos equipos con los que he trabajado. Es una situación curiosa, por que por un lado se transmite la necesidad de trabajar en pasos pequeños y por otro lado se usan prácticas que tienden a desincentivarlos.

Por lo que la forma de trabajo más común se parece al siguiente diagrama:


Además, en este caso, al generar PRs/MRs grandes, la code review, pierde sentido y en muchos casos se convierte en una pantomima (LGTM). (Ver: how we write/review code in big tech companies)

Con esta última forma de trabajar se mejora un poco el lead time hasta poner en producción, pero a costa de dar pasos más grandes, y de perder los beneficios de las code reviews serias.

Cuando se trabaja con code reviews asíncronas la realidad no suele ser tan sencilla como lo que hemos visto en los diagramas. La realidad suele incluir muchos flujos simultáneos y cruzados en el que existe una tendencia fuerte al trabajo individual y al cambio de contexto continuo.

De hecho, no se genera ningún incentivo para que el equipo trabaje con foco en una sola historia de usuario al mismo tiempo, puesto que cada uno estaría ocupado con sus propias tareas y haciendo code reviews asíncronas para los demás.

Otro problema que suele suceder es que las code reviews no tengan suficiente prioridad y se generen colas. Esto hace que el lead time crezca y que se desplieguen a producción cambios más grandes con el incremento de riesgos que ello conlleva.

¿No hay otras opciones?

Por suerte sí que las hay, las code reviews síncronas y las code reviews continuas.

Code review síncronas y con prioridad

El primer paso puede ser dar la máxima prioridad a las code reviews y hacerlas de forma inmediata y síncrona, entre el que ha desarrollado el incremento y el encargado de hacer la review.

Con esta forma de trabajar se consigue que el lead time total de cada incremento sea menor y se incentiva trabajar en pasos pequeños.

En este caso, como efecto colateral, las code reviews deberían ser más fáciles, puesto que la explica el propio desarrollador y puede expresar con detalle por qué ha tomado cada una de las decisiones.

Esta forma de trabajar requiere mucha coordinación entre la los miembros del equipo y no es sencillo hacerlas siempre síncronas, pero desde luego es un paso sencillo si ya estamos realizando code reviews asíncronas.

Realmente es tan simple como que las PRs/MRs tengan la máxima prioridad y que en cuanto tengas una preparada, te coordines con alguien para revisarla los dos juntos en un único ordenador.

Pairing/Ensemble programming: Code review continua

Programación en parejas: "Todo el código que se envía a producción es creado por dos personas que trabajan juntas en un mismo ordenador. La programación en parejas aumenta la calidad del software sin que ello afecte al tiempo de entrega. Es contraintuitivo, pero dos personas trabajando en un mismo ordenador añadirán tanta funcionalidad como dos trabajando por separado, salvo que será de mucha mayor calidad. El aumento de la calidad supone un gran ahorro en la fase posterior del proyecto". http://www.extremeprogramming.org/rules/pair.html 


Cuando trabajamos usando programación en parejas tal y como se recomienda en programación extrema, el código se diseña y desarrolla de forma conjunta por dos personas. Esta forma de trabajar genera una revisión constante del código por lo que no requiere una fase final de revisión. 

Desde luego, desde el punto de vista de coordinación, es el sistema más sencillo, puesto que una vez que se han formado las parejas, cada pareja se organiza para ir haciendo incrementos, que de forma implícita van siendo revisados de forma continua.

En este caso, el diagrama que representa esta forma de trabajo sería: 


A partir de la programación en parejas y viendo sus beneficios, ha aparecido una nueva forma de trabajar conocida como programación en grupo (mob/ensemble programming). En esta modalidad todo el equipo trabaja al mismo tiempo en un único cambio y usando un único ordenador. De esta forma todo el equipo colabora en el diseño de cada pieza de código limitando al máximo los cambios de contexto y minimizando el lead time de cada uno de los cambios. Al igual que en la programación en parejas, la programación en grupo realiza una revisión continua y sincrona del código.

De las formas de trabajar que hemos visto, la programación en pareja o en grupo, es la que tiene un menor lead time para cada cambio, menos cambios de contexto e interrupciones y requiere menos coordinación.

Aun así la programación en parejas y en grupo no es una práctica sencilla y requiere esfuerzo y mucha práctica. Lo que sí tengo claro es que lleva al extremo los beneficios de calidad que se suelen asociar con las revisiones de código.

Visión de la industria y personal

Si en una cosa parece estar de acuerdo la industria es que hacer code reviews es una buena práctica y que deberían hacer todos los equipos de desarrollo. Por otro lado también se recomienda en la mayoría de los casos trabajar en incrementos pequeños, de forma que se pueda controlar mejor la complejidad y el riesgo de cada uno de los cambios.

Teniendo en cuenta estos dos puntos, parece una buena idea usar Code Reviews y que estás sean lo más sincronas y continuas posible, de forma que podamos trabajar en esos incrementos pequeños de baja complejidad y bajo riesgo.

En mi caso, llevo unos cuantos año empujando la programación en parejas o en grupo, creando un flujo de incrementos pequeños que se revisan de forma continua.

Tanto en Alea Soluciones como en TheMotion, utilizábamos programación en parejas por defecto y programación en grupo ocasionalmente. La frecuencia de despliegue de ambas empresas era diaria, y podíamos hacer cambios considerables en pasos pequeños y seguros (3s). Además de este flujo de desarrollo constante y sostenible, obtuvimos atractivas ventajas adicionales, como la facilidad para difundir el dominio y el conocimiento técnico o hacer una rápida incorporación de nuevos miembros. En el caso de Alea Soluciones, contratamos a personas que ya tenían experician en programación en parejas y en prácticas XP, por lo que fue más fácil. Sin embargo, en el caso de TheMotion, tuvimos que introducir las prácticas XP (TDD, programación en parejas, etc.), por lo que contratamos ayuda de coaching técnico.

En Nextail había una mezcla de equipos que hacían programación en pareja y revisión continua y otros que utilizaban revisiones de código asíncronas pero las priorizando para evitar las colas.

En Clarity, algunos equipos utilizan revisiones de código asíncronas pero las priorizan para minimizar el lead time. Ya hay dos equipos que hacen revisiones de código continuas (utilizando la programación en parejas o en grupo) y estamos ampliando gradualmente esta forma de trabajar a otros equipos.

Por supuesto el valor estadistico de mi experiencia es nulo y es mucho más interesante analizar los resultados de analisis más serios como el DORA (https://www.devops-research.com/research.html). En ellos podremos ver como se asocian a equipos de alto rendimiento las siguientes prácticas:


Relacionado:

Sunday, July 25, 2021

Good talks/podcasts (Jul 2021 II)



These are the best podcast/talks I've seen/listen to recently:

  • Benefits Of Going Beyond The Make-It-Work Phase (Francisco Climent) [Agile, Technical Practices, XP, tdd, testing] [Duration: 0:40:00] Interesting talk about the benefits of using TDD in embedded systems. The talk is full of useful tips, patterns, and strategies very useful in both embedded and non-embedded environments. Special mention to how Francisco uses mutation testing in the development process.
  • DRY Software Patterns & Microservices (Dave Farley) [Software Design, Technical Practices] [Duration: 0:16:00] In this episode, Dave Farley of Continuous Delivery explores DRY, Coupling and Microservices and how they interact. Dave takes a pragmatic software engineering approach to exploring the pros and cons of DRY on different scales and describes why the microservices example may be more complicated than it looks.
  • Want More Value Faster? Take Many More Much Smaller Steps (GeePaw Hill) [Agile, Lean Software Development, Technical Practices, XP, tdd] [Duration: 0:55:00] (⭐⭐⭐⭐⭐) A must-talk for anyone trying to do lean/agile software development. The talk delves into the reasons why the strategy of using small, safe steps is the right one to steadily evolve a software system. I am very much aligned with this approach to software development.
  • The Trimodal Nature of Software Engineer Compensation: Why Positions Pay a (Very) Different Salar (Gergely Orosz) [Engineering Career, General, Management, Technical leadership] [Duration: 0:13:00] Interesting information about compensation /salary for software engineering positions in Europe mainly.
  • KEYNOTE Designing change (Jessica Kerr, Avdi Grimm) [Agile, Architecture, Evolutionary Design, Inspirational, Software Design] [Duration: 0:48:00] (⭐⭐⭐⭐⭐) The journey of a software developer is a climb through abstraction: algorithms, patterns, architecture.... How do we keep expanding scope, without losing focus on the real work? Join us for a journey into the fourth dimension, where we don't just change code; we design change.
Reminder, All these talks are interesting even just listening to them, without seeing them.

Related: 

Saturday, July 03, 2021

Good talks/podcasts (Jul 2021 I)

 

These are the best podcast/talks I've seen/listen to recently:

  • Traditional vs Modern Internal Platforms: Find the Differences! (Manuel Pais) [Devex, Devops, Platform as a product, team topologies] [Duration: 1:04:00] A very interesting discussion about the key differences between the traditional approach to internal platforms and tooling vs the modern approach.
  • ProductTank New Zealand - The What & Why of Continuous Discovery (Teresa Torres) [Lean Product Management, Product, Product Discovery] [Duration: 1:00:00] the best product teams are shifting from a project mindset to a continuous mindset. In this talk, Teresa explores the key differences between project-based discovery and continuous discovery and give your team a clear benchmark to aspire to.
  • How to Build Products Users Love with Kevin Hale (How to Start a Startup 2014: Lecture 7) (Kevin Hale) [Product, Product Discovery, Product Strategy, startup] [Duration: 0:48:00] Kevin Hale, Founder of Wufoo and Partner at Y Combinator, explains how to build products that create a passionate user base invested in your startup's success.
  • A Guide To Managing Technical Teams (Dave Farley) [Engineering Culture, Management, Technical leadership] [Duration: 0:17:00] In this episode, Dave Farley of Continuous Delivery offers his advice on leading software development teams. How do you make the step from developer to manager? How do you deal with difficult situations and conversations? What are some of the commonest mistakes that people starting out in team leadership often make?
  • Are you ready for production? (Jaana Dogan) [Devops, Engineering Culture, Observability, Operations, Platform] [Duration: 0:35:00] This talk examines practices from design & development, configuration management, observability, release management, capacity planning, security, and compliance.
  • Foundations of Modern Product Organizations (Gerard Chiva) [Company Culture, Lean Product Management, Product, leadership] [Duration: 0:41:00] (⭐⭐⭐⭐⭐) This talk explains the keys to the success of digital product organizations. Technology is an essential part of any business today, not just a cost center.
  • In Search of the Perfect Cloud Native Developer Experience (Daniel Bryant) [Cloud, Devex, Devops, Engineering Culture, Platform, Platform as a product] [Duration: 0:45:00] Interesting talk to understand different approaches to achieve an effective development flow in a cloud-based environment. X explains interesting ideas to create an internal self-service development platform to reduce friction for stream-aligned teams.
  • Testing Strategy for DevOps (Dave Farley) [Devops, Engineering Culture, Testing in production, testing] [Duration: 0:14:00] (⭐⭐⭐⭐⭐) Dave Farley describes his take on what a holistic test-strategy looks like, and gives us examples from the real world to describe it.
Reminder, All these talks are interesting even just listening to them, without seeing them.

Related: