Choose Boring Technology (2015)
A widely cited essay urging teams to “choose boring technology” prompts debate over when to favor proven, well‑understood stacks versus newer tools that promise higher payoff but add risk. Many engineers praise ideas like “innovation tokens” as a practical way to limit novelty to a few areas of a system, especially in startups or infrastructure where reliability, shared platforms, and maintainability matter more than résumé‑driven choices. Others argue that labels like “boring” are vague and can shut down proper evaluation, noting that context, team expertise, evolving ecosystems (from Node and Kubernetes to AI agents and LLM‑friendly stacks), and clearly defined requirements should drive technology decisions instead.
Innovation tokens & “boring” tech
- Many commenters still like the “innovation tokens” framing as a way to explain tradeoffs to non-engineers and keep risk concentrated in a few areas.
- Others argue the metaphor is fuzzy; decisions should be framed explicitly in terms of risk, testing, failure modes, and team expertise rather than “boring vs new.”
- Several people stress that “boring” is contextual: if a team already knows Node, Mongo, Rust, etc., those may count as boring for them.
Defining “boring”
- Working definition from the thread: tech whose capabilities and especially failure modes are well understood, with few “I didn’t know it could do that” surprises.
- Examples commonly cited as boring: Postgres/MySQL, PHP/Ruby/Django, cron, memcached, basic Linux + HAProxy stacks.
- Some argue that every system, including “boring” DBs, has many footguns; boring just means “least bad known quantity.”
Node, JavaScript, and ecosystem churn
- There’s broad agreement that Node itself is “boring” in 2026, but many see the JS ecosystem (npm sprawl, tool churn, supply-chain risk) as still non-boring.
- Debate over whether anything in the JS ecosystem can be called mature vs other languages.
Kubernetes and infra complexity
- Strong pushback on treating Kubernetes as boring; many see it as overkill for most companies and a major source of outages and cognitive load.
- Simple bare-metal or VPS setups with a small stack (Linux + Postgres + PHP/Python) are argued to be sufficient for most business apps.
Incentives, careers, and “CV-driven development”
- Several comments note that resume incentives and hero culture reward flashy tech and firefighting more than prevention and boring reliability.
- Others dislike terms like “CV-driven development,” seeing them as unfairly assigning bad motives.
AI/agents and boring tech
- Some suggest spending innovation tokens on AI/agents and pairing them with in-distribution, boring stacks that models know well (e.g., Django, PHP, Go).
- There’s concern that LLMs default to popular or hyped stacks (TypeScript/Next.js), skewing choices.
- Others argue LLMs actually make it easier to use older, simpler tech effectively.
Critiques of the thesis
- Critics say “choose boring technology” can become a thought-terminating cliché used to block appropriate innovation or justify ill-fitting legacy stacks.
- Counter-proposal: always “choose the most appropriate technology,” with boringness as just one factor among requirements, workload fit, hiring, and ops cost.