An effective software architecture is one that enables an organisation to sustainably iterate at a high velocity. This means that the teams building the software also have to be well architected. Software architecture is really sociotechnical architecture.

As sociotechnical architects, we must manage the dependencies in the design of the software system and the design of the organisation as well. Poor alignment results in handovers and politics between teams. It doesn't matter how great our software architecture is, if teams are blocked from innovating quickly, we can't reap the benefits of our beautiful architecture.

In Software Design X-Rays, Adam Tornhill showcases a powerful technique that every sociotechnical architect should have in their toolbox. Tornhill shows us how to design and evolve sociotechnical systems by analysing historical source code data.

The techniques and examples in this book knocked my socks off, and the results from analysing my own codebases were equally stunning.

Analysis Techniques & Design Heuristics

There are plenty of great examples to pick from the book, but one of my favourites is the section on code hotspots. Code hotspots are places that change frequently.

If we see that there are lots of developers all working in a hotspot, we know that it will be a coordination bottleneck - so we can use data to show how cleaning up the hotspot is a sensible business decision that makes economical sense.

To me, this is powerful. Instead of relying on biases and gut instinct, we can use data to have sensible conversations with the business rather than moaning like children about how messy the code is and how much we want to rewrite it.

Another analysis technique that thoroughly impressed me was the rate at which components co-change. Tornhill shows us how to produce analyses that identify modules that always change together. Why is this important, though?

When things change together, they are cohesive. If you don't know why cohesion in software is such an important heuristic, consider it your homework. You will thank me for it.

But cohesion isn't just a technical metric. If we can identify cohesion that exists between teams, we have identified a bottleneck. We can use that data to group the cohesion and remove a bottleneck between teams. To me, that's powerful, too. 

Also want to briefly mention that I loved the sections on using the data to challenge the domain model and code complexity trends.

This Book Was Written For Me

I loved every page of this book. I am passionate about designing quality software - obsessing over code to find the perfect design that future maintainers will find a joy to work with.

And I'm also passionate about finding the right boundaries in code and in organisations so that autonomous teams can focus on doing what they are best at and what makes them happy. It feels like this book was written especially for me.

There is so much potential in Tornhill's ideas, I hope that they become mainstream. I don't believe the current tooling is there yet. There's a lot of fiddling with bash scripts, transforming the data, and piping the results into visualisation tools (Tornhill has launched a commercial offering which is worth investigating but can't be trialled on private codebases)

If we can make better tools, these ideas can fundamentally impact the way we design software and organisations.