The Cult of Done Manifesto
“Done is the engine of more.”
— The Cult of Done Manifesto, Bre Pettis and Kio Stark, 2009
The manifesto is thirteen short principles, written in twenty minutes as a deliberate demonstration of its own argument. The gist: perfectionism is a stalling tactic dressed up as craft, so stop treating your work as precious, get it out of your head and into the world, and let the act of finishing generate the momentum for the next thing.
A few of its ideas that I keep coming back to:
- There are three states of being — not knowing, action, and completion — and pretending there’s a fourth (planning, researching, “getting ready”) is where most work goes to die.
- Anything not done yet is a draft, and accepting that removes the anxiety that stops you starting.
- Pretending you know what you’re doing is close enough to knowing what you’re doing, because you learn the thing by doing it, not before it.
- Failure counts as done, which reframes a dead end as progress rather than waste.
- Laugh at perfection — it’s boring and it keeps you from shipping.
The habit it breaks: premature optimisation
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”
— Donald Knuth, Structured Programming with go to Statements, 1974
The reason this manifesto lands for me is that my instinct runs the other way, and it costs me time. My failure mode isn’t rushing — it’s spending the first hour of a two-hour job solving a problem the job doesn’t have yet.
It shows up in a few recognisable shapes:
- Optimising for a scale that never arrives. Reaching for the partitioned Parquet layout, the index, the caching strategy, for a dataset that would comfortably fit in a spreadsheet.
- Solving for the second version before the first exists. Generalising a script into a configurable pipeline before I’ve run it end to end even once, for a use case I’ve imagined rather than met.
- Structure before substance. Folder layouts, naming schemes, and abstractions, agonised over on something that turns out to be one file and forty lines.
- Measuring the interesting thing rather than the slow thing. Tuning a step that’s two per cent of the runtime, because it’s the part I find fun.
Knuth’s line gets quoted as a licence for sloppy code, which isn’t what he meant — the sentence straight after it insists you should optimise the critical few per cent, once you’ve measured and know where it is. The point isn’t “don’t optimise”, it’s “don’t optimise blind”. And you can’t have measured anything before the thing runs.
That’s the join with the manifesto. Both are really claims about when information arrives: the answers to most of the questions I sit and deliberate over don’t exist yet, and finishing is what produces them. “Pretending you know what you’re doing” isn’t an argument for carelessness — it’s an admission that the armchair has nothing left to tell you. Shipping something imperfect is usually the fastest way to find out which of my four worries was the real one. More often than not, none of them was.
Why it works
For most of what I make, this is straightforwardly correct. A blog post, a one-off analysis, a scratch script, a prototype dashboard, a side project like this site — the cost of getting these wrong is that I redo them. The feedback loop is short, the blast radius is me, and the thing I learn from shipping a bad version is almost always more useful than the thing I’d have learned from another hour of planning.
Where the manifesto is right, though, it’s right for a specific reason: the cost of being wrong is low, recoverable, and paid by me. That assumption is doing most of the work, and it’s worth saying out loud — because it isn’t always true.
Where it breaks: database design
Schema design is the clearest case I know of where that assumption fails. Iteration isn’t cheap, the cost isn’t mine alone, and applying the manifesto literally produces genuinely expensive mistakes.
- Data outlives the code that wrote it. You can rewrite an application end to end over a weekend. The table it writes to has five years of history, four downstream consumers you’ve never met, and a report someone’s regulator reads.
- “Version 1 of anything is shit” doesn’t survive contact with 400 million rows. The manifesto assumes v1 can be thrown away. A populated table can’t be — it can only be migrated, which is a slower, riskier, and more political operation than a rewrite.
- Bad data is not recoverable, unlike bad code. This is the one that actually hurts. If you pick too coarse a grain, don’t capture effective dates, or overload a column with two meanings, you haven’t just written something you’ll refactor later — you’ve permanently failed to record information. No amount of future cleverness reconstructs a distinction you never stored.
- Done means other people start building on it. “Done is the engine of more” is exactly the problem: the moment a schema is done, views, extracts, models, and dashboards attach themselves to it, and every one of them becomes a reason it can never change.
- Names are an interface. Renaming a column is a five-second edit and a fortnight of breaking other people’s work.
There’s also a subtler mismatch. “Pretending you know what you’re doing” works when the domain will teach you as you go. Data modelling is mostly the act of pinning down what the business actually means by policy, claim, or customer — and getting that wrong isn’t a technical error you’ll notice in testing, it’s a semantic one that surfaces two years later when two teams’ numbers disagree and nobody can say which is right.
Reversible and irreversible
The useful way to hold both ideas at once is to sort schema decisions by how expensive they are to undo, and only apply manifesto speed to the cheap half.
| Cheap to change later | Expensive or impossible to change later |
|---|---|
| Adding a nullable column | The grain of a fact table |
| Adding a new table | What you chose not to capture |
| Adding an index | Primary and natural key choice |
| Widening a type | Narrowing a type |
| A view’s definition | A published column name or its meaning |
| A materialisation strategy | Whether history is versioned or overwritten |
The right-hand column deserves the deliberation the manifesto tells you to skip. The left-hand column doesn’t — and in practice, most teams that are slow at schema work are slow about the left-hand column while being careless about the right.
Keeping the useful half
What I actually take from the manifesto into data work:
- Iterate hard, but on a copy. Prototype the model against a sample in a scratch schema or a local DuckDB file, where being wrong is free. Move fast there, deliberately, and promote only once the grain and keys have stopped changing.
- Ship narrow, not shallow. The manifesto’s instinct to release early is sound if you scope down what the schema covers rather than how carefully it’s specified. One well-modelled entity beats six half-modelled ones.
- Make change cheap where you can. Versioned migrations from day one, expand-and-contract instead of in-place renames, and a view layer between the physical tables and consumers. This is how you buy back the right to iterate.
- Capture more than you need. Where storage is cheap and the decision is irreversible, err towards the finer grain and the extra timestamp. You can always aggregate later; you can never disaggregate.
- Still finish. None of the above is a licence for the analysis-paralysis the manifesto was written against. Deliberation is warranted on maybe five decisions in a schema. Everything else should ship.
The Cult of Done is a manifesto about momentum, not a design methodology, and it’s honest about that — it was written in twenty minutes to prove a point. The point stands. It just needs one qualifier: match your speed to the cost of being wrong, and in a database, that cost is paid by whoever inherits your data long after you’ve moved on.