Why a 2015 Slide Deck Is Back on Hacker News in 2026

An eleven-year-old slide deck keeps showing up in developer conversations again. It’s Dan McKinley’s “Choose Boring Technology,” written in 2015 and never revised. No new edition, no author’s remix, no anniversary repost. So why now? The answer probably has three letters in it.

One caveat before we dig in. This isn’t a measurable groundswell backed by traffic data — it’s the softer phenomenon of an old essay getting summoned into arguments over and over. There’s no massive thread volume to point at from the last month. So this piece is less about how many people are talking and more about why this particular text keeps getting pulled off the shelf right now.

The Innovation Token, Refreshed

McKinley’s argument is almost insultingly simple. Every company has a fixed number of innovation tokens. His rough figure: about three. Adopt a new technology, spend a token. Run out, and you have no capacity left for anything genuinely new.

The word “boring” here doesn’t mean bad. It means predictable. PostgreSQL, MySQL, PHP, Python — these technologies have their failure modes documented. When something breaks at 3 a.m., someone has already broken it the same way and written up the fix. A six-month-old tool offers no such thing. Nobody knows what happens when it fails, because it hasn’t failed enough times yet.

McKinley framed this as the gap between known unknowns and unknown unknowns. Mature technology gives you the first kind. New technology gives you the second. And it’s the second kind that takes companies down.

Why 2026 and Not, Say, 2020

The 2015 context was clear enough. Microservices and NoSQL were peaking. Startups were reaching for MongoDB with no schema-flexibility problem to solve. Ten-person companies were splitting their product into forty services because that’s what the conference talks showed. McKinley’s deck was a brake pedal aimed straight at that.

2026 is a different problem. Developers aren’t drowning in choices — they’re drowning in output. AI coding tools produce thousands of lines a day. The cost of picking up a new framework has collapsed. “I’ve never used this library” stopped being a blocker the moment you could just ask the model.

Here’s where it gets treacherous. Adoption costs fell. Operating costs did not.

AI Cut the Cost of Writing Code, Not the Cost of Fixing It

This is the crux of the current argument. AI assistants are genuinely excellent at the authoring phase. Boilerplate for a framework you’ve never touched, generated in five seconds. Working code without reading a single doc page.

Then production happens. When something fails in a way nobody anticipated, and that failure mode isn’t in the training data, the model has nothing. Mature technology comes with a decade of postmortems, Stack Overflow threads, and GitHub issues indexed across the internet — which is exactly the corpus these models learned from. A tool released three months ago? The model will confidently invent something plausible and wrong.

Which leads to a genuinely counterintuitive conclusion: AI may have raised the value of boring technology. The stacks AI knows best are the stacks with the most accumulated written history — which means the old, proven ones. Ask about React, PostgreSQL, or Django versus something that shipped last quarter, and the difference in answer quality is not subtle.

The Counterargument Is Not Weak

There’s a real rebuttal here. If AI flattened the learning curve, the case for stubborn boringness weakens. Learning a new framework used to cost weeks, and the whole team paid that tax together. That cost is now dramatically lower, and pretending otherwise is its own kind of denial.

There’s a second problem. Take McKinley too literally and you accumulate technical debt by inaction. An organization still running the stack it chose in 2015 because it was “boring” is probably still hand-solving problems the industry fixed years ago. Boring should never become an alibi for stagnation.

The honest answer sits in between. Innovation tokens are still finite, but where you spend them matters more than how many you have. McKinley said this explicitly: spend tokens on the thing that is your competitive advantage. Running a bleeding-edge log aggregation pipeline is waste. Running something novel at your product’s actual point of differentiation is the whole job.

AI Is the Non-Boring Technology Right Now

Step back and the picture gets a little funny. Most organizations have already dumped their entire token budget into AI. Agents, RAG pipelines, vector databases, prompt orchestration — all of it a few years old at most, none of it with a mature body of literature on how it fails.

Which translates McKinley’s advice into something very specific for 2026. If your tokens are all spent on the AI stack, make everything else as boring as you can stand. Keep the database on PostgreSQL. Deploy the way you already know works. Write in the language your team already speaks. AI alone is enough uncertainty for one system. Stack a new language and new infrastructure on top of it, and when the pager goes off you won’t even be able to isolate which layer broke.

That’s probably the real reason a 2015 essay keeps resurfacing in 2026. Not because the writing got better, but because the problem it was aimed at came back at a much larger scale.

Technology Choice Is a Risk Budget

Picking a stack isn’t a matter of taste. It’s a risk budget. The reason McKinley’s framing still holds eleven years later is that the total uncertainty a human team can absorb hasn’t grown much, even as the tooling around them has.

So: how many tokens is your team spending right now? And are they going toward the part of the product that actually differentiates you? If you’ve already spent one on AI adoption, one on a new framework, and one on new infrastructure, it’s worth deciding today what you’ll suspect first — because the next outage isn’t going to give you time to figure that out.