Choose Boring Technology
Every shiny new database is a promise to learn, at three in the morning, exactly how it breaks.
A few months after you bring in the exciting new database, there's a moment nobody warns you about. It's half past three in the morning. Something has gone wrong and the dashboards are telling you things that can't all be true at the same time, so you type the exact shape of your problem into a search engine. Four results come back. The first is the bug you happen to be living inside right now. The second is some bloke who asked the same thing back in 2021 and got no reply. Then there's the source code. And the fourth result is you, eight months from now, having finally figured it out, writing up the answer that the next poor soul is going to find at half past three in their own morning. Pick the boring database instead and there'd have been forty thousand results, and the third one down would just have told you what to do.
When you're choosing a technology you read the marketing and the benchmarks and that grid of features with the ticks in it. None of that stuff is what wakes you up at night. What wakes you up is how the thing behaves under the particular strange load of your own particular strange traffic, at the worst possible moment, and you can't see any of that until you're already in it. The evaluation only ever measures the brochure. What production measures is the way it falls over, which is a different thing entirely, and you don't get handed that second document until you're already in trouble.
This is the whole argument for boring, and the person who made it best is a man called Dan McKinley. Boring doesn't mean bad. It means mapped. A mature tool has sharp edges, but those edges have already cut a thousand other people who bled in public and then wrote down exactly where the edge was. Its failure modes are a known set, a finite one, and you can search them. The exciting tool's failure modes are an unknown set and you can't even guess how big it is, and that's about the worst kind of risk going, because there's no way to budget for a surprise you can't put a name to. You aren't picking between a tool that fails and one that doesn't. You're picking between failures that other people have catalogued for you already, and failures you're going to be discovering on your own, for the first time, while it's all happening live.
McKinley actually put a number on this and the number is harsh. You get roughly three innovation tokens. Three genuinely new choices you're allowed to make, and the supply doesn't loosen up until the rest of the system has gone and earned itself some stability. Most teams spend all three at once. And they spend them on the plumbing, a new database, a new queue, some new language runtime, and then they get to the actual product, the one thing a customer might actually pay them for, and there's nothing left in the budget. They've blown the whole allowance of weirdness on pipework that nobody is ever going to thank them for, and shipped more or less the same product as everyone else, late, sitting on top of three things they don't really understand yet.
The real currency was never the technology in the first place. It's what's inside your on-call engineers' heads. A company doesn't run on the best tools available. It runs on the handful of tools its tired people can debug from memory, half past three in the morning, without having to read anything. Every new technology you take on is one more separate thing to keep in a head that's already full, and what it costs you isn't the licence fee. The cost is the slow narrowing of how many people on the team can actually fix the thing when it breaks. A lot of the time that number ends up being one. And that one person, on the night it all matters, is lying on a beach somewhere with their phone turned off.
A mature tool turns up with this huge invisible structure built up around it, and you don't notice the structure until the moment you need it. The answered questions. The libraries that other people have already beaten into shape over the years. The stranger who hit your exact bug back in 2017 and left a note explaining how to get out of it. A consultant you can actually phone up. New technology has none of that yet, because nobody's had the time to build it. So you're not just using the tool. You're also its test team and its support forum and its institutional memory, all at the same time, unpaid, at the worst hour of the worst night. The spare-parts shop hasn't been built, and the only place the part exists is in your head, which is currently asleep.
None of this means you should never adopt anything new. Run nothing new for long enough and you'll be sat there filing punch cards while the rest of the world walks straight past you. It's an argument about where to spend the small amount of novelty you've actually got. Spend it on the one or two places where being different buys you something a competitor can't just copy, and then be dull everywhere else, almost embarrassingly dull. Choosing boring isn't losing your nerve. Surprises are coming for your system one way or another, they always do. The one thing you get to decide is whether they show up in the part you meant to be exciting, or down in the foundations at three in the morning with four search results and nobody having replied.
In the manifesto, this is tenets (XXI) and (I).
Sources
- [Brooks 1986] Frederick P. Brooks Jr., "No Silver Bullet: Essence and Accidents of Software Engineering". Proc. IFIP Tenth World Computing Conference, 1986. https://www.cs.unc.edu/techreports/86-020.pdf. Accidental complexity is the novelty you adopt and must carry, distinct from the essential problem; tenet XXI.
- [McKinley 2015] Dan McKinley, "Choose Boring Technology". mcfunley.com, 2015. https://mcfunley.com/choose-boring-technology. The innovation-token budget, boring-means-mapped, and the larger magnitude of unknown unknowns for new technology; tenets XXI, I.
- [Nygard 2007] Michael T. Nygard, "Release It! Design and Deploy Production-Ready Software". Pragmatic Bookshelf, 2007. https://pragprog.com/titles/mnee2/release-it-second-edition/. Production behaviour, not the feature grid, is what a new tool is actually judged on, and only under load; tenet XXI.
- [Ousterhout 2018] John Ousterhout, "A Philosophy of Software Design". Yaknyam Press, 2018. https://web.stanford.edu/~ouster/cgi-bin/aposd.php. Complexity as the cognitive load a maintainer must hold in their head; tenets XXI, I.
One of a series of field notes on building software for the way minds actually work: tired, distractible, ordinary, and now partly machine. They all lead back to the manifesto behind them, The Shape of the System.