Hoy he tenido el gran honor de participar en la conferencia Agile en Español - 1ª Iteración y de presentar "El coste basal y la falacia de la construcción".
Muchas gracias a Juan Banda por la invitación.
Slides
Documento Original (Con Notas)
Thursday, May 27, 2021
Charla: Coste basal y la falacia de la construcción
Sunday, May 16, 2021
Good talks/podcasts (May 2021 I)
These are the best podcast/talks I've seen/listen to recently:
- 36 - Building High-Performing Teams with Observability and CI/CD (Charity Majors) [Agile, Continuous Delivery, Engineering Culture, Inspirational, Technical Practices, Technical leadership] A high-performing team is one that gets to spend almost all of their time solving interesting problems that move the business forward. Not doing a lot of toil. Not working on things they have to do in order to get to the things they want to do.
- What Are Reactive Systems? (Dave Farley) [Architecture, Design, Microservices] Dave describes the use of Asynchronous messaging as the foundation of this approach and how a simple system built this way would be be fast, responsive, resilient
- Improving Oncall Support with Meaningful Alarms (Brian Scanlan) [Architecture, Architecture patterns, Engineering Culture, Operations] Robby speaks with Brian Scanlan, Principal Systems Engineer at Intercom. They discuss the benefits of having consistent software patterns across an organization, how run books are a must-have (and why they should be tested), and optimizing for developer productivity. Brian also talks about approaches to reducing deployment time and why it is so vital to be responsive to their customers.
- Ep. #4, Everything is an Experiment with Charity Majors and Liz Fong-Jones of Honeycomb (Charity Majors, Liz Fong-Jones) [Continuous Delivery, Engineering Culture, Operations] In episode 4 of Unintended Consequences, Yoz and Kim speak with Charity Majors and Liz Fong-Jones of Honeycomb about scaling teams and company values. They share how their team makes space for curiosity and learning as a group, and why this has been so important for the Honeycomb platform.
Reminder, All these talks are interesting even just listening to them, without seeing them.
Related:
How big is the backpack your organisation is holding
Author: Jorge Jardines https://www.gardenunez.net/
Every experiment, invalidated product feature or unused line of code you haven't deleted is adding weight to your backpack.
Every
morning when you wake up and need to walk the next X miles you feel the
weight in your back and you feel slower than yesterday. It is like
adding an extra bottle of water on your backpack, water you aren't gonna
drink but still needs to hold on your back.
Your team or
organisation is holding this huge backpacks all the time. Do you ever
wonder why adding a new experiment gets more and more slower and costly
for your teams, do ever check how much code isn't being used, how many
features are not being used I your product, how many "brilliant" ideas
were transform into code that nobody used. Do you ever wonder how big is
the backpack your organisation is holding.
References:
Monday, May 03, 2021
API contract & Expand. (Small Safe Steps)
In the latest Toughtworks tech radar (Vol 24 April 2021), API Contract & Expand appears as a technique to be adopted. I couldn't agree more.
We often use complex versioning mechanisms even if a more straightforward API expand and contract strategy works perfectly for most cases.
In general, API expand and contract should be enough for internal APIs. For external APIs, expand and contract should work for small changes, and API versioning is a better option for more significant changes.
If you want to practice this and other strategies to reduce risk and slice technical changes, please check out this Small Safe Steps workshop.
References:
Saturday, May 01, 2021
It's not only a waste; it's a burden
Talking about software systems, let's stop to talk about waste when we refer to something not necessary or created without a clear understanding of the problem to solve. Let's call it a burden (since you are going to have it holding you back forever)...
If you implement it to experiment, learn and later throw it away, perfect... If you are keeping it, you are fooling yourself.
This code is a burden, worse than the sunk cost, and it will generate a recurrent cost forever.
There are two types of complexity, the inherent and the accidental/incidental.
The inherent complexity can't be avoided because it is intrinsic to the problem we want to solve. But the accidental/incidental is all the complexity we introduce by not fully understanding the problem, not knowing how to solve it, or by our lack of mastery on the subject, etc.
This accidental/incidental complexity is also a burden. The inherent one is not. :)
Do yourself a favor, reduce the burden. reduce the basal cost. improve your life and the life of your team.
- Work in small steps
- Try to really understand the real problem and the meaningful impact you want to make
- Validate each increment and its impact
- Always work with quality-in and with attention to technical excellence
- Refactor continuously (to reduce the accidental/incidental complexity)
- And for God's sake, delete everything that is not necessary. Ruthlessly remove; code, dependencies, features, complexity… Minimize basal cost and make the evolution of the system easier.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity --the art of maximizing the amount of work not done-- is essential.
References:
Subscribe to:
Posts (Atom)