§ 91
Choose Boring Technology
Every unfamiliar technology a team adopts brings unknown failure modes and a permanent operating cost, and a team can afford only a few of them.
Keep in mind
Spend new technology only where it sets you apart
What to do
Before adding a language, datastore or framework, write down what it would take to do the job with what you already run and why that falls short, and make the decision with everyone who will operate it, not inside one team. Spend new technology only where it sets the product apart. When you do adopt something, plan to retire what it replaces.
Why it happens
Most of a technology's cost is paid after launch: keeping a system working reliably for years costs far more than the convenience it bought while building. With a mature tool the failure modes are well understood because someone has already hit them; with a new one the unknown unknowns are larger, and the team discovers them in production. Each addition is also one more thing to monitor, hire for and keep patched, and that cost stays after the novelty wears off. So novelty is a budget, not a free choice: McKinley gives every company about three innovation tokens.
When it stops applying
Fitness for Purpose: boring is not the same as never new; when the existing stack genuinely cannot do the job, forcing it costs more than a token, and a stack that never moves becomes the legacy nobody wants to work on.
Source
Dan McKinley, Choose Boring Technology (mcfunley.com, 2015) — "every company gets about three innovation tokens", drawn from his years at Etsy.
Read the sourceCite this
Hammurabi, § 91, “Choose Boring Technology.” https://kanywst.github.io/hammurabi/laws/choose-boring-technology/
BibTeX
@misc{hammurabi-choose-boring-technology,
title = {Choose Boring Technology},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 91},
url = {https://kanywst.github.io/hammurabi/laws/choose-boring-technology/}
}