The case for boring software

A lot of working software is, on close inspection, boring.

Boring is not a failure of ambition. Boring is a feature. Boring software is software that:

• —Works on a Tuesday.
• —Will still work in 2034.
• —Doesn't require a paid consultant to install.
• —Doesn't break when the framework releases v3.
• —Reads, in code, the way it reads in a meeting.

The most powerful enterprise stack I've ever shipped did one thing very well, with no novelty. The most loved consumer feature I've shipped also did one thing, very well, with no novelty. Both took me twice as long as the exciting alternatives. Both still run today.

Boring scales. Novel breaks.

The reason the rest of us chase shiny is mostly social. We are paid in conference talks and tweets. Boring software gets neither. The most quietly successful systems on earth — the SAP screens, the bank ledgers, the airline reservation databases — are run by people whose names you will never know.

The trade is straightforward. Boring buys you decades. Shiny buys you headlines. Decades compound. Headlines don't.

I am not against shiny. I have helped ship plenty of it. I'm against confusing 'shiny' for 'progress.' These are the same word in some industries. They aren't in software.

What I optimise for now

• —Could a junior engineer fix this on their first week? If not, why not?
• —Could I delete a dependency this quarter and not feel it?
• —When this breaks at 3am, will the on-call know what to do?

Three questions, asked weekly, will keep most of your codebase from drifting into theatre.

If your codebase is exciting, something is wrong.