The-Artificer-of-Ciphers-LLC Choose Boring Technology
"Consider how you would solve your immediate problem without adding anything new." — Dan McKinley, 2015
The core idea
McKinley's essay argues that every new technology you adopt is a "complexity token" you spend — and you only have a limited budget. Novel technologies bring unknown failure modes, thin internal expertise, and higher cognitive load. Boring technologies (well-understood, widely deployed, battle-tested) have predictable failure modes, rich documentation, broad community knowledge, and don't surprise you at 2am.
The law doesn't say "never adopt new tech." It says: be deliberate about when you do, and have a high bar.
How to apply it
Step 1 — Solve the problem with what you have first. Before evaluating any new option, ask: can you solve this with something already in your stack? A Postgres table instead of a new cache? A cron job instead of a message queue? The answer is often yes, and the boring solution is usually good enough longer than you expect.
Step 2 — Budget your complexity tokens. Assess how many unfamiliar technologies are already in flight on the team. If you're already running Kubernetes, a new microservices framework, and a new language, adding another unknown is risky. Teams have limited capacity to learn and operate things reliably.
Step 3 — Score the tradeoff honestly. Ask these questions about the proposed tech:
- Does anyone on the team have real production experience with it?
- What does failure look like, and do we know how to recover?
- Is there a boring alternative that covers 80% of the use case?
- What's the operational cost (monitoring, on-call, upgrades)?
- Are we adopting this because it actually solves our problem, or because it's interesting?
Step 4 — Prefer addition over replacement. If you do adopt something new, keep the old thing running where it already works. Don't rip and replace — introduce incrementally and let the new thing earn its footprint.
When boring is the right call (almost always)
- Startups and small teams: operational complexity kills small teams. Default to managed services and proven stacks.
- Under time pressure: debugging unknown tech under deadline is brutal.
- Core infrastructure: databases, queues, auth — these need to be boring.
When new tech is worth it
- The boring alternative genuinely can't do the job (not just "does it less elegantly").
- You have team members with real production experience in it.
- The expected lifespan of this system justifies the learning investment.
- You've prototyped it and it behaved predictably under realistic conditions.
Key questions to surface
When helping someone with a tech decision, work through:
- What's the actual problem we're solving?
- What's the simplest thing that could possibly work?
- What do we already have that we could stretch?
- If we adopt this, who will be on call when it breaks at midnight?
- Are we choosing this for us, or for the engineers who come after us?