The Case for Boring Technology

Every engineering team has a fixed budget of complexity — cognitive, operational, and maintenance complexity combined. The question isn’t whether to spend it, but where. Teams that spend complexity budget on novel technology choices have less budget available for solving their actual business problems. Teams that choose deliberately boring technology tend to ship faster, have fewer production incidents, and have easier hiring.

What Boring Technology Actually Means

Boring technology isn’t old technology. It’s technology that’s been in production long enough that its failure modes are well-understood, the operational practices are well-documented, and the talent market for people who know it well is deep. PostgreSQL is boring. Nginx is boring. Linux is boring. They’re boring because they work, reliably, at scale, and have worked that way for decades.

The Cost of Novelty

New technology has hidden costs that don’t show up in the initial proof of concept: limited operational experience in the industry, immature tooling, sparse documentation of edge cases, and small talent pools. These costs are real, they compound, and they’re paid mostly during the incidents you’ll have at 2am, not during the architecture review where you chose the new technology.

The Right Time for Novel Technology

Novel technology is appropriate when the specific capability it provides is unavailable in mature alternatives, when the domain genuinely calls for it, and when you have the capacity to absorb the operational uncertainty. “This is interesting” is not a sufficient reason. “This is the only way to solve this specific problem” might be.