The book
What this is
Eighty thousand words, six parts, thirty-one chapters, four interludes and an epilogue — about craft, the machine that ships it, the people, a trial of the process, deciding, and the one person in the labyrinth you can't reorganize.
It is a practitioner's book, not a survey. Almost every chapter opens with something that actually
happened: a payment system with exactly one reader; a function called processData
with seven hundred lines behind it; a comment saying temporary fix, remove after the
migration that turned out to be six years old and load-bearing; a deployment runbook whose
step nineteen had been wrong for two releases; a sticky note that attended thirty
retrospectives and changed nothing; three people who knew about the bug and said nothing for
two days; a man who owned a database the way a medieval lord owns a bridge.
Running underneath all of it is one project. Project Ariadne was a consumer platform that moved real money, built from the ground up by five teams that became nine, on three stacks that never reconciled, and it was eventually scrapped and restarted from scratch. It is the spine of the book, fed out in fragments across it.
The central idea
Software is a human problem wearing a technical costume. Pull the costume off any hard problem in this field and there is a person under it — a colleague, a user, a decider, a self — every single time. Ariadne did not die of technology. The stacks were fine; the decision to run three of them unreconciled was human. The teams were skilled; the silence between them was human. Every machine in that building did what it was told.
That thesis is not new. What is new here is the price of the evidence, and the willingness to argue with it.
How every chapter is built
The same shape, thirty-one times: a war story that actually happened; the argument, in a handful of sections; a box called the honest counterargument where the other side gets its best case at full strength; in most chapters, a list called practicing it for Monday morning; and a closing paragraph called the thread — the chapter compressed into something you can hold on to when you come back to it in a year.
The counterarguments are the reason to trust the rest. Four of them are on this site, collected, unedited, before you have spent anything.
Who it's for — and who it isn't
It is for developers three to fifteen years in who have sat through the ceremonies and suspect the problem isn't the code; for new and reluctant tech leads; and for anyone who has watched a well-funded project fail while everybody was busy. It reads best next to Peopleware, The Pragmatic Programmer and Staff Engineer.
It is not for you if you want a methodology you can install on Monday. Part IV spends five chapters prosecuting exactly that, and the constructive chapter at the end of it deliberately refuses to sell a replacement framework. It also swears, in the chapter titles, on purpose.