Human DevOps

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

Published about 1 year ago • 2 min read

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

by Richard Bown

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's good to recognise our changing preferences as we move through the world of software engineering and use those moments to choose the right tool for the job. Sometimes we want to create, sometimes we want to retrench - perhaps refactor something, improve something, add more tests, change our architecture either subtly or fundamentally. In the world of SaaS and open source, we have more than just language, cloud or platform choices. We have tool choices which can mean that we do less...

13 days ago • 1 min read

I have an emotional reaction to peanut butter that is so strong, it’s actually physical. I feel physically sick getting it on me, cleaning it off a surface, or even contemplating eating it. Why? A story. When I was seven, my parents sent me to a preparatory school. During the weekdays, I would board—I would stay over—in a dormitory with other kids around my age. I would come home on Friday night and then leave again for school on Sunday afternoon. I dreaded it. At least, to begin with, I...

20 days ago • 1 min read

I'm sitting on the sidelines watching another big digital transformation roll into town. Those who have tried this before before know that big digital transformations don't work, so we're better not calling them that. Instead, these days we talk about cultural change. Realistically though this means the same thing. How can you recognise one happening in your firm? Well, suddenly there are a lot of meetings, and workshops looking backwards and training looking forwards. Some people might call...

27 days ago • 1 min read
Share this post