Prefer Boring, Proven Parts
You get a small budget of novelty. Spend it on the one problem only you have, and choose boring, proven parts for everything else — because boring's failure modes are already understood.
What changed›
- New chapter — added in the June 2026 restructure.
Principle Nº Six
Spend novelty like a budget. Default to boring where it doesn't matter.
Here is a frame that changed how I choose what to build on: imagine you get a small handful of innovation tokens — say three — and every genuinely novel, unproven choice you make spends one. A new database, a new language, a new framework, a clever architecture nobody on the team has run before: each is a token gone. You only get a few, because each novel part carries a hidden tax you'll pay later, alone, at the worst possible time.
“Boring” technology is boring precisely because its failure modes are already understood. The proven datastore has been run into the ground by thousands of people before you, and every way it breaks is on the internet with a fix beneath it. The exciting new one hasn't — so when it fails, and it will, you're the one discovering how, in production, at midnight. The dull truth underneath all of this is that the long-term cost of keeping a system working reliably vastly exceeds whatever convenience a shiny choice bought you during the week you built it.
Where the tokens belong
Restraint here is the twin of subtraction from Principle Nº Two: that one governs what you remove, this one governs what you let in. Both are forms of disciplined less. And the point isn't to never innovate — it's to aim your novelty. Spend your tokens on the one problem that is actually yours, the thing that genuinely differentiates the work and that no boring part can solve for you. Everywhere else, boring is what funds the interesting part: every proven, forgettable choice you make frees attention and reliability to pour into the place novelty actually earns its risk. It's worth remembering, too, that the simpler “good enough” design often outlives the more correct, more elaborate one, simply because it was easy enough to spread and survive.
Don't
Adopt the exciting new framework for a solved problem because it'd look good to have used it. That's a token spent on nothing.
Do
Reach for the proven, well-understood part for the solved problem — and save the token for the thing only you are building.
Where it goes wrong
Spend every token and the whole system is novel, which means every part can fail in a way no one has seen, all at once — you've built something exciting and unsupportable. The opposite failure is hoarding all three forever: refusing anything new on principle, ossifying around tools that genuinely stopped being the right ones. The budget is small, not zero. Boring by default doesn't mean boring always — it means novelty must justify the token it costs, every time.
Put it to work
List the genuinely novel or unproven choices in what you're building right now — the parts you'd have trouble finding a stranger's answer about at 2am. Count them against your three tokens. For each one over budget, ask the honest question: is this the problem only I have, or am I just bored? Trade the bored ones back for something boring, and feel how much risk quietly leaves the system.
Grounded in Dan McKinley's “Choose Boring Technology” (innovation tokens) and Richard Gabriel's “Worse Is Better.”