The Case for Boring Technology

A small team I knew once spent eleven weeks migrating a database that worked perfectly well to one that promised to work better. The old database held maybe forty thousand rows. You could have queried it with a wet finger and a magnifying glass. The new one was distributed, eventually consistent, and discussed at conferences in the reverent tone usually reserved for vintage wine. By the time they were done, the product hadn't changed at all. The users noticed nothing. What the team had actually built, at considerable expense, was a more fashionable way to store forty thousand rows.

I think about that migration a lot, because it was nobody's fault and everybody's. No single decision was foolish. Each step had a reasonable-sounding justification. It was the accumulated weight of a hundred small preferences for the new over the proven, and it cost a quarter of a year that could have gone to the thing the company actually sold.

The token you keep spending

There's a useful idea, originally from Dan McKinley, that every team gets a small ration of what he called innovation tokens.¹ Maybe three. With each one you may choose a single genuinely novel, unproven technology to build on. Spend a token on a new database, fine. Spend another on a new language. But you only get three, and once they're gone you're out, and everything else you reach for has to be aggressively, almost insultingly boring.

The trick is that most people spend their tokens on the wrong things. They blow all three on the plumbing — the queue, the datastore, the deployment system — and arrive at the actual hard problem, the thing customers are paying for, with empty pockets. The novel database doesn't make the product novel. It just means that when the product breaks at 3 a.m., you're debugging two unfamiliar things at once instead of one.

Boring technology is boring in a precise and valuable sense. It means the failure modes are known. When PostgreSQL or a Unix cron job or plain old HTTP breaks, it breaks in a way someone has already broken it, written about, and answered on a forum eight years ago. The long tail of weird edge cases has been walked by ten thousand people before you, and they left footprints. That accumulated boredom is an asset. It is, in fact, most of what you're buying.

The exciting thing about exciting technology is that nobody yet knows how it will let you down.

New tools are seductive because their flaws are still hidden. The demo always works. The blog post is always triumphant. What you can't see at the moment of choosing is the specific 3 a.m. that tool has waiting for you — the failure nobody has documented yet, because nobody has gotten far enough to hit it. You will be the documentation. You will be the forum post that someone else gratefully finds in 2031.

Boring as a feature

I want to be careful here, because "use boring tools" curdles very easily into "never learn anything," and that is not the argument. The argument is about where you point your appetite for risk. Risk is a budget, not a virtue. You should absolutely take wild swings on the problem that makes your work matter, the part where being slightly ahead of everyone else is the entire point. Everywhere else, you want the most tedious, most documented, most widely deployed option available.

The good reasons to reach for boring are unglamorous and decisive:

• The thing has been load-bearing for a decade, which means its remaining bugs are the rare and patient kind.
• You can hire people who already know it, instead of paying to train them on a tool that may not exist in three years.
• When you search the error message, you get answers, not a single unresolved thread from a stranger with your exact problem and no replies.

Underneath all of this is a deeper point: novelty is a cost disguised as a benefit. Every new system in your stack is something a future person — quite possibly you, tired, with less context than you have now — has to hold in their head. Complexity is paid not once at the moment of building but continuously, forever, by everyone who comes after. The boring choice is a gift to that future person. The exciting choice is usually a loan taken out in their name.

The cultural problem is that nobody gets promoted for boring. You don't get invited to give the talk titled "We Used Postgres and It Was Fine." The incentives all push toward the novel, the rewritten, the migrated, because those are legible as work, as initiative, as a thing you did. Keeping a stable system stable looks, from the outside, like having done nothing at all. This is one of the quiet tragedies of the field: the best infrastructure decisions are invisible precisely because they worked.

The most senior engineers I trust are not the ones who know the most tools. They are the ones who have been burned enough times to feel a specific dread at the word rewrite, and who have learned to ask, every time, the only question that matters: what does the user get that they didn't have before? If the honest answer is a more fashionable way to store forty thousand rows, the senior move is to close the laptop and go home.

Choose boring technology, then, not because you've stopped being curious, but because you've decided where your curiosity is allowed to cost something. Save the wonder for the work. Let the foundation be dull.

The most radical thing you can build, in the end, is something that just keeps running.