We've spent trillions of dollars trying to digitally transform business, but for the most part, we are still building poor-quality software systems. We've not learnt from our past mistakes. Instead, we think that by bolting on more and more systems, toolkits and frameworks, we can 'solve' how to build great and integrate software.

DevOps and CI/CD should enable a faster flow of quality software, but our implementations are often lacking. They pay lip service to the tools and processes but don't fundamentally fix anything. They actually make our lives more complicated.

Additionally, we've learnt nothing about how to build good software in a way that is either sustainable or attractive to software developers. If anything, the software development world is more of a grind than twenty years ago. It is a tick-box exercise for the most part: development, testing, architecture, and infrastructure. We are told what to build, how to build it, and why by experts who claim their own versions of 'best practice' are the one true path.

So what did we miss?

We missed Conway's Law. We missed understanding that the social system that builds the software directly affects the software we're building. While the profile of Conway's Law has been raised through the advent of 'socio-technical' understanding and important books like Team Topologies, we still fundamentally fall into the same old behaviour patterns.

Why? Many companies have tried agile and digital transformations and want to simply 'buy' a solution to the issues underlying their software delivery. This doesn't work. It's proven that this doesn't work.

So, as I look forward to ​Fast Flow Conf 2024​ in September, I wonder what the message will be this year. How can we change our behaviour to build better software?

My theory is that we have framework weariness. Rather than worrying about it or trying to change them, it's more about how to change DevOps processes from within engineering. No big transformations, just start with one person, connecting with others and opening minds. If we listen to each other's perspectives as engineers and leaders, we'll build an organisation that implicitly understands how to solve customer problems.

This is not a framework; it's a way of working. It's not measurable or predictable, but it's provably effective.

--

This week, I announced that I'll hopefully publish my debut novel later this year. I decided to write a book that explores how important our relationships are to building successful software systems. It's inspired by books like The Unicorn Project with a less didactic and, hopefully, slightly more human approach. I'll announce updates via this newsletter and publish more details over the coming months on the Human Software website (click on the link to stay informed).

-- Richard

​Residues: Time, Change, and Uncertainty in Software Architecture – Barry O’Reilly​

Published on June 12, 2024

​Read more...​