Choose Boring Technology, Except Where It Matters

"Choose boring technology" is one of the few pieces of engineering advice that is both widely repeated and mostly correct. The original framing, from Dan McKinley, is that you have a limited number of innovation tokens, and spending them on infrastructure means not spending them on your product.

I agree with it. I also think the way it gets repeated has become unhelpful, because it is used to end conversations rather than have them.

The useful version is not "use Postgres and shut up". It is: you get about one interesting technical decision, so know which one you are making.

Why boring wins by default

The case is strong and worth stating properly before arguing with it.

Failure modes are documented. When Postgres does something strange at 2am, somebody has written about it. When your novel database does something strange, you are reading source code. The value of a mature technology is not that it has fewer bugs, it is that its bugs have been encountered and written down.

Hiring is easier. Not just recruiting, onboarding. A new engineer who knows Postgres is productive on day two.

Tooling exists. Backup tools, migration tools, monitoring integrations, query analysers. All of it accumulated over decades.

The community answers your question. A Stack Overflow answer from 2019 that still applies is genuinely valuable, and it is a thing that only exists for stable technology.

You can leave. Popular technologies have migration paths off them, because enough people have wanted to leave.

Against that, the case for something new is usually a capability you can approximate, a performance improvement you have not measured, or that it is more enjoyable to work with. Those are weak arguments and they lose most of the time, correctly.

Where the advice gets misapplied

Three ways I see it used badly.

Treating all novelty as equal

The cost of a novel choice is not uniform. It depends almost entirely on how much of your system depends on it and how hard it is to reverse.

A novel database is expensive. It touches everything, your data lives in it, and migrating off is a project measured in quarters.

A novel build tool is cheap. It touches your CI, and switching back is an afternoon.

Those are not the same decision and the same advice should not apply to both. A team that uses Postgres and a new bundler has spent almost nothing. A team that uses Postgres and a novel distributed queue at the centre of their architecture has spent a great deal, even though it is one token in each case by a naive count.

The question is not how novel, it is how much would it cost to be wrong.

Ignoring that boring choices also age

"Boring" is not a permanent property. Technologies pass through interesting, boring, and then unmaintained.

Choosing something because it is established, when its community is shrinking and its maintainers have moved on, is not the safe choice. You are buying the appearance of stability. The failure arrives later and is worse, because by then nobody is writing about the failure modes either.

The signal worth checking is not age, it is whether the thing is actively maintained and whether the people who know it are still entering the field.

Using it to avoid understanding the problem

The pattern that bothers me most: "we should use boring technology" as a way to skip the analysis of whether the boring technology solves the problem.

Postgres is an excellent default and it is not a queue, a search engine, or a cache. It can be pressed into all three and there is a real threshold past which it stops being the right answer. Deciding by slogan means finding that threshold in production.

Where to spend the token

The useful reframing: your one interesting choice should be the thing your product is actually about.

If you are building a real time collaboration product, the CRDT layer is where novelty is justified, and everything else should be aggressively boring.

If you are building an infrastructure product, the infrastructure is the product, and you may need to make several unusual choices in that area while being extremely conventional everywhere else.

I run an infrastructure company built on Firecracker microVMs, which is not the boring choice. Containers are the boring choice. But the whole product is about isolation properties that containers do not provide, so the interesting decision is the reason the company exists. Meanwhile the control plane is a conventional web application with Postgres behind it, because there is nothing to gain from being clever there.

That is the shape I would look for. One interesting thing, load bearing, chosen deliberately. Everything else dull.

The questions worth asking

Before adopting anything unusual:

What specifically can we not do with the boring option? A concrete requirement, not a preference. "Postgres cannot do X" where X is something a customer needs. If you cannot name it, you do not have a case.

How would we find out this was wrong? A novel choice that fails silently for eighteen months is much worse than one that fails loudly in a month. What is the signal, and how soon does it arrive?

What is the exit cost? Not whether you can leave, but how long it would take and what would break. If the honest answer is a quarter of engineering time, that is the actual price of the decision.

Who is the second person who understands this? A technology that one person understands is a person shaped risk. This is the question that most often changes my mind, because the answer is frequently "nobody yet" and there is no plan for that changing.

What happens when it breaks at 2am? Is there documentation, a community, a support contract, or is there a source tree? For the failure modes you cannot anticipate, the difference between a searchable error message and an unsearchable one is enormous.

The version of the advice I would give

Be boring by default, deliberately interesting once. Know which one is your interesting choice and be able to say why.

Weight the decision by reversibility, not by novelty. A one way door deserves an argument. A two way door deserves an experiment.

Boring at the bottom, interesting at the top. Data storage, runtime, and deployment should be dull. The layer where your product's actual value lives is where you are allowed to do something unusual, and where you probably have to.

Prefer boring things that are actively maintained over old things that are merely familiar.

Revisit occasionally. Today's interesting choice is next year's boring one, and today's boring one is sometimes next year's liability. The decision is not permanent and should not be treated as sacred either way.

The underlying point is that "boring" was always a heuristic for managing risk under uncertainty, not a value in itself. Applied thoughtfully it is one of the best heuristics in the field. Applied as a slogan it becomes a way of not thinking, which is the opposite of what it was for.