An 11-year-old essay by Dan McKinley just hit 377 points on Hacker News with 201 comments — and it's more relevant in 2026 than it was when it was written in 2015. "Choose Boring Technology" is the kind of essay that every senior engineer eventually discovers, usually after learning its lessons the hard way.
The Core Idea: Innovation Tokens
McKinley's central metaphor is elegant: every company gets about three innovation tokens. You can spend them however you want, but the supply is fixed for a long while. You might get a few more once you reach a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet.
If you choose to write your website in NodeJS, you just spent one innovation token. If you choose to use a new service discovery tech that's existed for a year or less, you just spent one innovation token. If you choose to write your own database — oh god, you're in trouble.
Any of those choices might be sensible if you're a JavaScript consultancy or a database company. But you're probably not. You're probably working for a company that is at least ostensibly doing something else — rethinking global commerce, reinventing payments, or pursuing some other suitably epic mission. In that context, devoting your limited attention to innovating SSH is an excellent way to fail.
What "Boring" Actually Means
"Boring" should not be conflated with "bad." There is technology out there that is both boring and bad — you should not use any of that. But there are many choices of technology that are boring and good, or at least good enough:
- MySQL is boring. Millions of production deployments, well-understood failure modes.
- Postgres is boring. Decades of battle-testing, extensive documentation.
- PHP is boring. Runs a huge fraction of the web, including Facebook.
- Python is boring. The workhorse of data science and ML infrastructure.
- Memcached is boring. Simple, fast, does one thing extremely well.
- Cron is boring. The most reliable scheduler ever built, present on every Unix system.
The nice thing about boringness is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. You know what happens when MySQL hits 100% CPU. You know what happens when PHP-FPM runs out of workers. These are known unknowns.
New technology, by contrast, brings unknown unknowns — things you don't even know to worry about. Maybe your new graph database's garbage collector pauses when writing stats. Maybe your new service mesh has a subtle bug that only manifests at scale. You won't find these in the documentation because nobody has run it long enough to write them down.
Why This Essay Resonates in 2026
In 2026, the temptation to adopt exciting technology is stronger than ever. AI tools promise to make new technology adoption painless — just have the AI agent set up the new framework! But McKinley's argument cuts deeper than implementation difficulty:
The cost of technology is not in adoption. It's in operation.
Adding technology to your company comes with a cost. You have to monitor it. You have to figure out unit tests. You need an init script. You need to understand its failure modes. You need someone on call who knows how to debug it at 3 AM. All of this adds up fast.
The "best tool for the job" thinking takes a myopic view of "best" and "job." Your job is keeping the company in business. The best tool is the one that occupies the "least worst" position for as many of your problems as possible.
The Three Innovation Token Budget in Practice
McKinley's framework is particularly useful for evaluating AI infrastructure choices in 2026:
Scenario A: You're an e-commerce startup.
- Innovation token 1: Using an AI-powered recommendation system (new, but core to your business)
- Innovation token 2: Building on Kubernetes (new-ish, but solves real infra problems)
- Innovation token 3: Writing your checkout in a new language like Zig (WHY?)
- Result: You're out of tokens. The Zig checkout is going to fail in production and nobody will know how to fix it.
Scenario B: Same startup, different choices.
- Innovation token 1: Using an AI-powered recommendation system
- Everything else: Postgres, Python/Django, Redis, standard monitoring
- Result: You have two tokens in reserve for when you actually need them. Your infrastructure is boring and reliable. You spend your energy on the business problem.
When to Choose New Technology
McKinley doesn't advocate for never adopting new technology. He advocates for a deliberate process:
- Consider how you would solve the problem without adding anything new. If the answer is "we can't," you're not thinking creatively enough.
- Write down exactly what makes the current stack prohibitively expensive. This forces specificity — vague complaints about "performance" aren't enough.
- Set clear expectations about migration. If the new technology overlaps with existing systems, commit to migrating.
- Get company-wide visibility. New tech has company-wide effects, so the decision needs company-wide input.
The key insight: if the "problem" is that someone really wants to use the technology, abort immediately. Technology for its own sake is snake oil.
The Etsy Lesson
McKinley draws from his experience at Etsy, which suffered from "polyglot programming" — hiring Python programmers and creating a pointless middle layer just to give them something to do in Python. It required years of effort to amputate. Meanwhile, the 90th percentile search latency was about two minutes.
The lesson: adding technology to solve a social problem (making developers happy) creates a technical problem that outlasts the social one.
What This Means for AI-Era Teams
In 2026, the "choose boring technology" principle has new applications:
AI frameworks: Don't build your product on a framework that released v0.1 last week. LangChain v0.1 was a nightmare; let the ecosystem mature.
Vector databases: Postgres with pgvector is boring. It works. You probably don't need a dedicated vector database until you have millions of embeddings.
Model serving: Ollama and vLLM are becoming boring. That's a good thing. Don't build your own inference engine.
Agent frameworks: This is the current frontier of "innovation token" spending. If you're building an AI agent, that's probably your one token. Don't also switch to a new database, a new frontend framework, and a new deployment system at the same time.
The Freedom in Boring
McKinley's most powerful point is his conclusion: mindful choice of technology gives engineering minds real freedom — the freedom to contemplate bigger questions.
When your infrastructure is boring, you can think about your business. When your infrastructure is exciting, you can only think about your infrastructure.
The teams that ship great products aren't the ones using the newest technology. They're the ones who chose boring technology, understood it deeply, and spent their innovation tokens on the things that actually matter to their business.
Eleven years later, with 377 points on Hacker News and 201 comments, it's clear this lesson needs to be relearned by every generation of engineers. The technology changes. The principle doesn't.
Based on "Choose Boring Technology" by Dan McKinley, originally published July 27, 2015.
Top comments (0)