I wrote a book.

That sentence still feels slightly surprising to type, even though the book has been finished for a few weeks now and is about to be available on Amazon. I have been writing about software development, technology policy, and the gap between how organisations think about technology and how it actually works on this blog for longer than I care to calculate. It turns out that if you write about the same cluster of ideas for long enough, from enough different angles, with enough accumulated frustration at watching the same failures repeat themselves with different names, you eventually have something that wants to be a book rather than a series of posts.
Book cover Code is Design

This is that book.

It is called Code Is Design, and it will be available on Amazon in both eBook and paperback form in a few days. Here is what it is about and who it is for.

The argument

The book has a central claim, and I will state it plainly: software development is not a construction activity. It is a design activity. The code is the design – rendered in the only notation precise enough to express it completely and without ambiguity. Everything that precedes the code – the requirements documents, the wireframes, the architecture diagrams, the sprint plans – is not design. It is pre-design: useful, sometimes essential, but always provisional, always incomplete, and always subject to revision the moment it encounters the reality of implementation.

This is not a new idea. If you have been reading this blog for a while, you will recognise it – I have been making versions of this argument, in various contexts and with various degrees of restraint, for years. What the book does is make the argument properly: with historical grounding, with specific analysis of the specific mechanisms that keep the wrong model in place, and with practical guidance for what to do differently.

The wrong model has a name. I call it the construction myth – the belief, embedded in the industry since the late 1960s and reinforced by fifty years of institutional practice, that software development is fundamentally similar to building a bridge. That you can design the system upfront, estimate its cost precisely, hand it to a team of developers to build, and receive the result on the promised date within the promised budget. You cannot. The evidence for this has been accumulating for five decades. The book makes the case that the evidence is conclusive and examines, in some detail, why the myth has survived it.

Who the book is for

The short answer is: anyone who has been in a software project that went wrong and wondered why.

The longer answer has two parts.

If you are a developer – someone who writes code for a living, or leads teams that do, or has spent enough time in the industry to have developed that particular combination of technical fluency and institutional frustration – you will find that the book says things you already know. Not in the way that a book about obvious things is unsatisfying, but in the way that having precise language for your own experience changes your relationship to it. I have tried to give you the vocabulary to explain your reality to the people around you who need to understand it. That vocabulary is the part of the book I most wanted to exist and could not find anywhere else.

If you are a manager, a client, a product owner, or any of the other people who commission, fund, and oversee software development without writing it – the book explains something you may have suspected but never quite been able to articulate: that the process by which most organisations build software is structurally misaligned with the nature of the work, and that the failures you have witnessed are not the result of bad luck or incompetent vendors. They are the predictable, structural, entirely avoidable consequence of applying the wrong mental model to a domain it does not fit. The book names that model, explains where it came from, and describes in practical detail what to replace it with.

I have tried, throughout, to write a book that a developer can hand to their manager and a manager can hand to their developer – one that both audiences will recognise as honest about their respective positions rather than partisan toward either. Whether I have succeeded is for readers to judge. But that was the intention.

Where the book came from

Regular readers of this blog will know that I have been thinking about these ideas for a long time. Some of the arguments in the book started as posts here – written in the heat of a specific frustration, published, and then returned to over the years as new experience either confirmed or complicated the original thinking. The blog has been, among other things, a place to work out what I actually think about things – to put an argument in writing and discover, in the process of writing it, whether it holds.

What the book does that the blog cannot is hold the argument together across its full length. A blog post makes a point. A book makes a case – a sustained, structured, evidence-based case that builds from chapter to chapter and arrives somewhere specific. The ideas in Code Is Design are not new, in the sense that I have been thinking about most of them for the better part of my career. What is new is the form: the careful sequencing of the argument, the specific analysis of the mechanisms that perpetuate the dysfunction, and the practical framework for doing something about it.

I am also conscious that writing a book is a different kind of commitment from writing a blog post. A post can be revised, updated, walked back if the thinking changes. A book is a stake in the ground – a declaration that this is what I think, argued as carefully as I can argue it, at this point in a career that has given me more material than I ever wanted on the subject of why software development so often goes wrong.

Forty-five years of commercial development experience is a long time to watch an industry repeat the same mistakes with different names. Writing the book was, among other things, an attempt to say clearly what I have seen – in the hope that some of the people who read it will see it too, and make different choices as a result.

What happens next

Code Is Design will be available on Amazon in a few days – I will update this post with the link the moment it goes live. It will be available as both an eBook, priced at $12.99, and a paperback.

If you have been reading this blog and have found the ideas here useful or interesting or worth arguing with, I think you will find the book worth your time. If you know someone – a developer who is tired of explaining their reality to the people above them, or a manager who has commissioned one too many projects that did not deliver what was promised – who would benefit from having a framework for understanding why that keeps happening, I would be grateful if you passed it on.

The argument begins on the first page. I hope it is worth the read.