In praise of boring technology

Every engineering team gets a small budget of what I've come to think of as innovation tokens. You can spend them on a novel database, an unproven language, a bleeding-edge deployment target — but the supply is strictly limited, and the exchange rate is brutal. Spend them all at once and you'll find that the interesting problems you wanted to work on are buried under a landslide of incidental complexity that nobody chose on purpose.

The counter-intuitive move, then, is to be aggressively boring about almost everything. Reach for the database you already understand at 3am. Pick the framework whose failure modes are documented in a thousand Stack Overflow answers. Save your tokens for the one or two places where novelty is the actual point of the product.

What "boring" actually buys you

Boring is not the same as bad, and it is certainly not the same as easy. A boring technology is one whose capabilities and, more importantly, whose failure modes are well understood. You know how it breaks. You know what the fix looks like at 3am. You know which of its sharp edges have already drawn blood, because someone wrote it down.

The nice thing about a well-worn tool is that the internet has already made every mistake you're about to make, and written it down. — a principle I keep relearning

Consider a concrete case. Suppose you need a background job queue. The exciting answer involves a dedicated broker, a new operational surface, and a fresh on-call runbook. The boring answer is often a table:

-- A job queue that fits in the database you already run.
SELECT id, payload
FROM   jobs
WHERE  run_at <= now()
  AND  status = 'pending'
ORDER  BY run_at
FOR UPDATE SKIP LOCKED
LIMIT  10;

Three words — FOR UPDATE SKIP LOCKED — turn an ordinary table into a safe, concurrent work queue with no new infrastructure to run, monitor, or explain to the next engineer. Is it the right answer at a million jobs a second? No. But you are almost certainly not doing a million jobs a second, and pretending otherwise is how token budgets get blown.

Spending the tokens you saved

The point of hoarding boring choices is not asceticism. It's leverage. The tokens you don't spend on your queue, your cache, and your deploy pipeline are tokens you get to spend on the thing that actually differentiates the product — the recommendation engine, the real-time collaboration layer, the physics simulation. That is where novelty earns its keep, because that is where being ordinary would make you ordinary.

I've watched teams get this exactly backwards: a genuinely novel product built on a stack so exotic that the team spent all its energy keeping the lights on and had nothing left for the idea that justified the company. The interesting bit shipped late, half-finished, on top of a foundation nobody fully trusted.

A rule of thumb

When you're tempted by something new, ask what you'd have to give up to run it well: the on-call knowledge, the debugging intuition, the library ecosystem, the ability to hire people who've seen it before. If the new thing isn't paying for all of that and then some, put it back on the shelf. The shelf is not going anywhere.

Boring technology is a gift you give your future self — the one holding the pager, reading this very sentence by the glow of a laptop at an hour when nothing exciting should ever be happening in production.