choose-boring-technologylisted

# 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 d