There is a bias in technology toward novelty that is almost never acknowledged as a bias. New frameworks, new architectures, new paradigms — they are presented as progress, and the team that adopts them early is presented as sophisticated and forward-thinking. The team that uses established, well-understood tools is presented as conservative, behind the curve, or simply boring.
This framing is backwards. Boring technology is usually the right choice. Exciting technology is usually the wrong one. Here is why this is so hard to accept, and why it matters enormously for the quality of what you build.
What boring technology actually means
Boring technology is not old technology. It is not inferior technology. It is technology that is so well-understood, so well-documented, and so widely used that its failure modes are known and its edge cases are covered in the documentation. When something breaks, there are Stack Overflow answers. When you hire a new engineer, they are likely to know it already. When you need to debug something at 2am, you are not also debugging the tool itself.
PostgreSQL is boring. Redis is boring. React is becoming boring. These are boring technologies in the best possible sense — battle-tested, widely understood, and reliably excellent. Their boringness is evidence of their quality, not a sign of their obsolescence.
The hidden cost of excitement
Exciting technology comes with hidden costs that are not visible at the moment of adoption. The documentation is sparse or incomplete. The community is small, which means fewer resources when you hit problems. The best practices have not yet been established, which means you are discovering them the hard way. The team needs to upskill, which costs time. And the fundamental premise of the technology — the architectural decision it embodies — may turn out to be wrong in ways that are not apparent until you are deeply committed.
These costs compound. A team that spends 20% of its engineering time dealing with the idiosyncrasies of its novel stack is a team with 20% less capacity to build the product that users actually need. The exciting technology is consuming the engineering attention that should be going to the hard problems in the business domain.
When to use exciting technology
Sometimes the novel tool is the right choice — when the problem genuinely cannot be solved with boring technology, when the novel tool provides an advantage that is directly proportional to the product's core value proposition, or when you are explicitly in the business of pushing the boundary and have the engineering resources to absorb the cost.
These situations are rarer than the technology industry would have you believe. Most products do not need cutting-edge infrastructure. They need reliable, maintainable, understandable infrastructure. The infrastructure's job is to disappear — to be so solid that you never have to think about it — so that you can focus on the product.
The real sophistication
The sophisticated engineering team is not the one using the newest tools. It is the one that correctly identifies which tools are right for the job, resists the social pressure to adopt novelty for its own sake, and makes technical decisions based on what the product and the team actually need.
This requires a kind of intellectual courage that is undervalued: the courage to be boring when boring is right. To choose PostgreSQL over a trendy distributed database when you do not actually need distributed. To choose a simple REST API over GraphQL when your frontend has a clear, stable data model. To build the boring thing and build it well.
The goal is not the technology. The goal is the product. Keep that clear, and the technology decisions become much simpler.