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

Read more...

The Human Software

Software systems rule our world. My regular newsletter explores the human factors that make software engineering so unique, so difficult, so important and all consuming.

Read more from The Human Software
Human Software 272 - Impatient, Needy Writers

Writers are terribly impatient. We are so fragile, we crave attention all the time. So, for us, writing into a vacuum and not getting anything back is the worst. We will happily take anything including "wow, it really sucked" or "how could you be so old and so feeble at writing?" At this point in the journey of Human Software, I'm so desperate for feedback, I'm even willing to pay for it! So that's what I did. In January, I hired an editor, and he's been great. He helped me with the...

Human Software 271 - Drawing Inspiration from History

Over the last week, I drew a map of Kent reimagined as if the 1286/7 floods hadn't happened. According to the history books, those large storms and tidal events significantly changed the coastline of eastern England. The former Wantsum Channel became blocked with alluvial mud and sand, turning the once important seaport of Sandwich into a landlocked town too far away from the sea to accept large boats. Further afield Dunwich in Suffolk suffered a similar fate: In the Anglo-Saxon period,...

Human Software 270 - Finding Something to Say

Three years ago, I started a podcast without much idea of its future. Before that, I'd started writing, wandering through automation, programming techniques, infrastructure, DevOps, and thoughts about management, leadership, and how companies are organised. Where was I going? While I'd read a few books, it was clear that I was searching for something. Was I just talking for the sake of it? It sometimes certainly seemed that way. And then, about eighteen months ago, I started writing a novel....