Book Review: Software Design X-Rays

Software Design X-Rays


Adam Tornhill

My Rating

star star star star star
"A game changer. Tornhill showcases a data-driven approach to evolving sociotechnical systems."

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.


"Good code is as much about social design as it is about technical concerns."

"Technical debt is a strategic business decision rather than a technical one."

"Change coupling is invisible in the code itself - we mine it from our code's history and evolution."

"Identify the files most frequently touched, and improve those for the biggest gains."

"Not only do our change frequencies let us identify the code where do most of the work, they also point us to potential quality problems."

You may also like...

Domain Driven Design


The Economist Guide to Organisation Design

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design
The Strategic Practices of Domain-Driven Design