choose boring technology
expressionprogrammingops culture
Dan McKinley's principle: prefer proven, well-understood tools, and spend your few innovation tokens deliberately.
Boring means known failure modes, deep operational lore, and answers on the first search-results page. The essay's framing - each team can afford maybe three genuinely novel choices - turned technology selection from taste into budgeting.
Dan McKinley's argument is that a team has a limited budget of innovation tokens, and that spending them on infrastructure leaves none for the product that actually differentiates the business. Boring technology means well understood, with known failure modes, existing expertise and a decade of other people's mistakes already documented.
The case rests on what novelty actually costs. A new datastore is not just a new datastore; it is unknown operational behaviour under load, an unfamiliar backup and recovery story, a small hiring pool, immature tooling, and failure modes that nobody has written about yet, all of which are discovered during incidents rather than during evaluation. The mature alternative is unexciting and its problems are searchable.
The important qualification is that boring is relative to your team rather than absolute. A technology your people have run for years is boring for you regardless of its age, and the industry standard is exotic if nobody there has operated it. The argument is not against ever adopting anything, it is that each adoption should be a deliberate expenditure justified by what it uniquely enables, and that most systems should be assembled from things whose behaviour is already known.
Also known as: innovation tokens