The project
Project Ariadne, in one page
The book tells this story in fragments, across a dozen chapters, because that is how it was lived. Here it is in order, once, so you can see the whole shape of it. In the myth, Ariadne is the one who hands over the thread. We went in without it.
-
01
It began as a prototype
A proof of concept, commissioned to answer one question: could the company build the replacement for its ageing betting platform itself? It started honestly, the way prototypes do — move fast, prove the idea, skip everything that slows you down. Skipping the craft was not a mistake. It was the point.
-
02
The concept was declared proven
And then nothing was thrown away. Nobody wrote a death date down; nobody re-founded the proof as a product. The promotion from prototype to platform was not a decision, it was a drift, and it arrived in the least dramatic sentence in software: it already works, why rebuild?
-
03
Three stacks, three groups
The back end was .NET, the front end Angular, and a set of services ran on Elixir. Each was defensible alone; none was ever reconciled with the others. Every border between technologies was also a border between groups of people, and every border between groups was a place where conversations didn't happen — which is exactly where the brittle interfaces appeared.
-
04
Five teams became nine, then eleven
Two of the later teams arrived from a second city and started working inside other people's code without a word to them. The project scaled its headcount steadily. It did not scale its judgment, and the gap between the two is where the money went.
-
05
One database, one man
Entity Framework had been banned as too slow — true for the betting engine, irrelevant for the management screens most teams were actually building. So every read and write went through hand-written stored procedures, and by an arrangement nobody remembered making, only one person wrote them. A dozen teams' data-layer changes funnelled into a single inbox. Features that were “done” sat waiting for their tables.
-
06
The deciding happened outside the room
Product owners planned features. Architects — capable ones, good engineers — cancelled those plans from the side, arriving at review with a picture of how the code should have been written and a list of finished work that would now be redone. Direction changed depending on who you had spoken to last. Above all of it were directors who had been excellent engineers before the promotion took them out of the code.
-
07
A full day producing nothing
Every path was blocked: on another team's endpoint, on a schema change in the queue, on a design decision nobody had the authority to close. Not a slow day — a zero. It was not an anomaly either; it was the system working as designed, and it is the day the book opens on.
-
08
One word meant five things
A feature was “done” — merged and passing tests, to us. Deployed to staging, to the team downstream. Seen and nodded at by a stakeholder, to the product owner. Signed off, to QA. Conforming to a design document half of us had never read, to the architect. Five teams, each running flawless Scrum internally, and a chasm between them that no ceremony spanned.
-
09
Stop. Merge everything.
A new technical head arrived, looked at three years of parallel progress and gave the only order left: every team stops building features and merges what exists into one working system. The integration week showed everyone's true face. Features reported green for months met each other for the first time and detonated on contact. One week taught the company more about the state of its project than three years of sprint reviews had, and everything it taught was bad.
-
10
Scrapped
Totally. Millions spent, nothing shipped that survived. A new technical director started again from scratch with new teams — which is a bloodless way of saying that people were fired. The most expensive thing I ever helped build became a line item in someone's lessons-learned deck.
What actually killed it
None of these is technical. That is the whole argument of the book, and this is where it was paid for.
- A prototype nobody threw away
- Production load arrived on a schema designed in an afternoon to answer a yes/no question. in the lexicon
- A queue of one
- A dependency is a queue, and queues compound. Nobody decided that a betting platform should advance at the speed of one man's inbox — but nobody decided otherwise either, and in dependencies the default always wins. in the lexicon
- A batch size nobody questioned
- We questioned the architecture, the branching, the teams, the languages. Nobody asked why we were integrating three years of divergence in one bite. in the lexicon
- Authority without accountability
- Architects decided; teams owned the failure. Product owners owned outcomes and controlled no inputs. The chair where the two should sit together had been sawn in half. in the lexicon
- Silence at every seam
- Below the configuration, below the queue, below the code, there were two humans and a silence. That is the five-whys of almost every disaster I have attended. in the lexicon
- Growth outrunning judgment
- You can hire engineers quickly. You cannot manufacture seniority quickly, and a project making more decisions with less judgment per decision is autocompleting into walls. in the lexicon
I was inside it, as a developer, for the middle of it. I said some of this out loud at the time, to lead engineers and to architects, and not much changed — the system had taught its veterans not to see exactly what a newcomer couldn't help seeing. Then it ended, and I spent years working out what it had actually been.