In praise of boring technology

Earlier this year my team migrated a piece of routing infrastructure from a cluster of fashionable services to a single Postgres database with a dozen tables and three cron jobs. We removed about forty thousand lines of code, deleted four background services, and watched our p99 latency drop by a factor of three. Then we went out for drinks.

The story is unremarkable. Half the engineers I know have a version of it. We replaced a streaming pipeline with a cron. We replaced three queues with a single Postgres table. We replaced a "real-time" notification service with a thirty-second polling loop. None of these were technical breakthroughs; they were exercises in subtraction.

I want to argue that this kind of subtraction — the deliberate choice of unfashionable, well-understood, slow-moving tools — is the most underrated craft skill in software engineering. And that boring technology, far from being a constraint, is something to actively cultivate.

What "boring" means here

Dan McKinley's essay "Choose Boring Technology" introduced the phrase a decade ago and it's never aged. The idea, briefly: every team has a finite budget of innovation tokens, and every novel technology you adopt — a new database, a new language, a new orchestrator — costs one. Spend them carefully, because most projects don't need them.

Boring, in this sense, is a description of a tool's failure modes, not its features. A boring database is one whose failure modes have been catalogued by ten thousand strangers on the internet over fifteen years. A boring deployment system is one where every weird edge case has a Stack Overflow answer dated 2018. The boredom is the feature.

Three boring tools I keep coming back to

Postgres

Postgres is a database. It is also a queue, a key-value store, a job scheduler, a search index, a feature store, a graph database, a geospatial engine, a JSON document store, and — using LISTEN/NOTIFY — a pub/sub bus. You won't be the best at any one of these things using Postgres. You will be good enough for almost any company that isn't a hyperscaler. You'll have one operational runbook, one backup story, one query language to teach to new hires.

I have replaced Redis, Elasticsearch, RabbitMQ, and (twice) Kafka with Postgres tables. None of these were ideologically motivated; in each case the new system was already doing what Postgres could do, and the operational burden of running it had become disproportionate to the value.

rsync over ssh

I deploy this blog with rsync -avz --delete site/ deploy@example.invalid:/var/www/site/. There is nothing else. No CI, no GitHub Actions, no Vercel webhook, no edge function. The command is in a four-line shell script in the repo root. It runs in under a second. It has not failed once in two years.

rsync was first released in 1996. It is older than most of the engineers I've hired. It has zero direct competitors because no one is trying to compete; the niche is exhaustively occupied. rsync is the platonic boring tool.

Plain-text files

Most of what I write at work is in plain text files. Notes in a journal/ directory committed nightly. A todo.txt at the top of every active project. Meeting agendas in markdown. The text-file medium is boring in the highest sense: any tool I will ever use can read it, no schema migration is ever required, and "syncing" is just git push.

The argument I usually hear against this

It's some version of: "but we'll outgrow Postgres / rsync / a cron". This is occasionally true. Far more often it's prophylactic engineering against a problem the team will never have. Outgrowing Postgres takes years for most companies. Most companies don't last that long. And on the margin, the team that postpones the migration to the fancy new thing for one more year tends to be the team that ships the most product in that year.

I'd rather be the team that ships product. The fancy thing will still be there when we genuinely need it, by which time it might also be boring.

The discipline of choosing nothing

Choosing a boring tool is, to be honest, less satisfying than choosing an exciting one. There is no announcement on a tech-news aggregator. No conference talk to give. No recruiter is impressed that your stack includes cron. The reward is the absence of incidents at 3 a.m., months later, accumulated quietly and without any single moment of triumph. You'll forget you made the choice, which is the point.

Boring is the most underrated kind of engineering courage. It says: I have considered the universe of options and deliberately picked the one that no one will ask me about. I picked it because I want to spend my finite attention on the actual product, not on running infrastructure. I want to go home at six.

I find this more romantic than any new framework.