A few years back I kept reaching for the newest, shiniest tool for every job. New database here, a fresh build system there, a cool new language on the side. Each one felt like progress. Each one was also a promise I'd be paying off for years.
Dan McKinley saw this clearly long before I did. In 2015 he published the essay "Choose Boring Technology," a talk he'd give the same year at OSCON in Portland while working at Stripe, after years as an early engineer at Etsy. The piece quietly rewired how a lot of teams think about tech choices, and it's aged better than most hot takes.
"Boring" doesn't mean bad
The first thing to clear up: boring is not a put-down. McKinley said as much almost apologetically, because the word invites the wrong reading. Boring means well-understood. It means you know what the thing can do, and just as importantly, what it can't. You can list its failure modes in advance — not because it never breaks, but because when it breaks, nobody is surprised and everybody knows the fix.
He rattled off a list that would make any stack-ranking fan wince: MySQL, Postgres, PHP, Python, Memcached, Squid, Cron. Nothing here gets you to the front page of Hacker News. That's exactly the point. The capabilities of these tools are documented, the mistakes have all been made by someone else, and the answers to your strangest edge cases are a web search away. When the stakes are "keep the company in business," that familiarity is the whole game.
Spend innovation tokens carefully
Here's the idea that stuck with me most: innovation tokens. Picture a finite budget for trying new things. Every fresh technology you adopt spends a token. You might have three or four in your project's lifetime, not thirty. The trap that McKinley warns against is blowing them all on infrastructure — the parts of the system users never see — instead of saving them for the product features that actually touch customers and can differentiate you. Innovating ssh is an excellent way to fail, he wrote. Your innovation is better spent where the customer can feel it.
Every tool carries a price tag
The deeper argument is about cost, not just taste. Choosing a technology is easy. Living with it is hard. Every addition comes with a perpetual maintenance cost — the team members who must know it, the docs to keep, the on-call pager that goes off at 2am. That cost often outstrips whatever convenience attracted you in the first place. One clever tool is a bargain; three clever tools are a tax on everyone who touches the system.
This is why McKinley pushed for the smallest set of technology that actually gets the job done. And it's the grain of truth in his slightly prickly advice that the tool you hate the most is probably the one you should use — because the one you "hate" is usually the one you already know intimately, failures and all. Hatred, here, is just the name we give to deep familiarity. A tool you truly know beats one you barely understand, however elegant the newcomer looks on paper. Boring, it turns out, is the sound of the future not breaking.