In Praise of the Unfashionable: Why Boring Technology Keeps Winning
Photo: vintage server room rows of unglamorous data center hardware, via www.shutterstock.com
There is a particular kind of apology that appears in engineering presentations across corporate America: the sheepish admission that a critical system runs on, say, a fifteen-year-old relational database with a single deployment artifact and no service mesh. The presenter lowers the slide quickly, as if the audience might judge.
They should not lower the slide. They should be proud of it.
This piece is an argument for the unfashionable — for plain databases, monolithic deployments, and tools so mature they have stopped appearing on conference agendas. It is also an argument against a hiring and design culture that quietly punishes engineers for choosing well over choosing new.
The Performance Advantage of Being Boring
Consider what a so-called boring stack actually buys. A monolith deployed on a proven runtime has one failure domain, one log stream, one deployment pipeline, and one place to look when something breaks at 2 a.m. A distributed system built from a dozen fashionable services has, in exchange for its flexibility, a dozen failure domains, a dozen dashboards, and a class of partial-failure bugs that simply cannot exist in simpler architectures.
The pattern VZDR has observed across enterprise interviews is consistent: the teams shipping fastest are rarely the ones with the most modern diagrams. They are the ones who spend their engineering hours on product problems rather than on operating the machinery of sophistication. Distributed tracing, circuit breakers, and multi-region failover are genuinely remarkable technologies — for the problems that genuinely require them. Most business problems are not those problems. Most business problems are, at their core, forms, workflows, and reports — problems that a boring relational database has solved superbly for four decades.
Resume-Driven Development Is a Hiring Problem, Not Just a Design Problem
It is fashionable to blame individual engineers for resume-driven development — the tendency to adopt technologies that look good on a LinkedIn profile. But the incentive structure is built by employers. Job postings in major US tech markets routinely demand microservice experience, specific orchestration platforms, and the current AI-adjacent tooling, even for roles maintaining systems where none of it applies. Engineers respond rationally: they build with what the market rewards, not with what the problem requires.
The result is a quiet tax on American software. Every migration to a trendier architecture consumes senior engineering capacity that could have shipped customer value. Every new operational dependency adds hiring requirements that widen the talent gap. And every fashionable failure mode — the clever event-sourced system nobody can debug, the Kubernetes cluster maintained by one indispensable engineer — eventually lands on the incident calendar.
What the Winners Are Actually Running
Strip away the marketing and examine the infrastructure behind companies known for velocity, and a humbler picture emerges. Many of the most effective mid-market engineering organizations in the United States run on Postgres, a single deployable application, background jobs, and a caching layer — technologies so stable that their release notes are boring by design. Their competitive advantage is not architectural novelty; it is the absence of architectural overhead. When the entire system fits in one engineer's head, features ship in days. When it spans six teams and eleven services, features ship in quarters.
None of this means stagnation. Boring technology is a current choice, made deliberately, not a default inherited from 2009. The discipline lies in the test: adopt the new thing when the problem demands it, not when the conference season suggests it.
A Modest Proposal for Hiring Managers
If enterprises want engineers who choose well over choose-new, the job descriptions have to change first. Ask candidates to describe a system they kept simple and why. Reward engineers who retire complexity, not only those who add it. Treat a well-run monolith as the achievement it is.
The unfashionable stack will never trend, and that is precisely its value. Fashion is expensive; boring is dependable. In a market where the winners are determined by how fast they can ship and how rarely they fall over, dependable is the most competitive technology choice available.
