Friday 7th April - How To Make Better Software, Faster

New beginnings throw working practices into sharp relief. What worked somewhere doesn't necessarily work somewhere else. Even quite small decisions in tool selection and working practice can have a big impact when they become part of the working methodology. What do I mean? Let's say a team of 10 developers have been working on a new product for a year, they've made some progress but management wants to speed things up so in short time, 10 becomes 30 developers. Do they suddenly see a speed up in the throughput of work? No. Should they expect this? No. Why?

If you've not read the Mythical Man Month then perhaps this is a good time to add it to your collection. I read it at University as part of my software engineering minor and it's a book that has resonated in the last thirty years of building software... until I read the Unicorn Project. Why? Because everything described in these books actually happens in day-to-day software engineering practice - and has done for over forty years now.

Despite regular reminders, software engineering is still a mystery to many. The naive view persists that we can treat software engineering as a manufacturing process - more people equals more output.

Software is not an output from a software engineering process. All there are are outcomes. And often because the outcomes are abstract it's hard to know when to make a change.

Here's another example. A group of the best developers and architects are pulled into a project that will define the infrastructure for a project. They build the machines, or kubernetes infra, they create the pipelines, they create the standards. This is a platform for the rest of the development organisation to use - but this team of individuals sees themselves as too senior to support the developers in using the platform they have created. They will create, but not support. And why should they? They were persuaded to create this new thing by management who had no concept of what they would build.

Whose fault is it that developers cannot reliably deploy to the new infrastructure? Is it the developers shortfall of knowledge? Is it the architects fault for making it too complicated? Or not supporting it? Is it the management's fault for staying too hands off with this process?

So how do you help someone understand something different in a different way?

Similarly when we build deployment pipelines - do we think that having Pull Requests and working in a Gitflow manner is helping our customers?

It's the start of conference season, and I'm shocked by the price/value return for many of them but one I can recommend without having been there is the Fast Flow Conference in London at the end of May. This brings together the Team Topologies experts from around the world. Applying systems thinking and Lean methodologies to our software delivery processes is crucial, now more than ever. Small decisions have big consequences. I hope to see you there.

Enjoy your Easter break!

-- Richard

Doing Gitflow means you’re leaving Business Value on the Table

Published on April 4, 2023

Gitflow means using different branches to develop software. It was invented to help software projects cope with multiple developers making simultaneous changes to a single codebase. It was a good thing when it was invented – better than merge conflicts – but it was only ever a workaround to a workaround. Namely how do you… Read More »Doing Gitflow means you’re leaving Business Value on the Table


Human DevOps

DevOps at is the heart of modern software systems. In my regular newsletter, I dive into the human factors that make successful engineering organizations where teams and platforms thrive at the heart of your socio-technical systems. From leadership to team setup, maximizing performance, tools and techniques.

Read more from Human DevOps

It has not by any means been a good summer in the Netherlands. It's been very wet and the last few days have also been extremely windy. At work, on the streets and on the roads, there is a tension. I try to take the time to go out for a lunchtime walk at least a couple of times a week and took this photo last week during a gap in the rain. The Middelpolder And we head towards the summer break, make sure to take some time to relax before you face the serious business of relaxation. I'm taking...

I lived in London in 1997 when the Tony Blair "New Labour" government swept into power. It was a time of great hope and audacity. It felt like "we" could do anything, but then I was 25 years old and living in London, and indeed, anything did, in fact, feel possible because I was at the dawn of my career without responsibilities or the weight of history behind my thoughts and actions. So perhaps older and wiser, we are here. The UK has been (according to some) bitten down by 14 years of Tory...

Do you always want more? More opportunities, more recognition for your work, more advancement? Sometimes, it's just knowing more, solving problems, and being right. What do we do to ourselves as software engineers and programmers that makes us want to do more all the time? We want to know more, write more, read more and perhaps even present more. I was interacting with someone on LinkedIn this Friday, and it made me reflect on what I am doing now compared to what I did a year ago. A year ago,...