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. 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 real sports-betting platform, built from the ground up by five teams that became nine and then eleven, on three unreconciled technology stacks, and it was eventually scrapped in its entirety. It is the spine of the book, fed out in fragments across a dozen chapters, and it pays off three times.
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 exactly what it was told.
That thesis is not new — Peopleware said a version of it in 1987. 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; three to six argued sections; a box called the honest counterargument where the other side gets its best case at full strength; 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. Ten 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 six 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.