Boring technology as a feature
Why we default to old, widely-used, aggressively unfashionable technology — and when we break our own rule.
When KPRS picks a stack for a new system, the default answer is almost always the older, more widely adopted, less fashionable option. We build on Postgres far more often than on the hot new OLTP database. We write a lot of plain-boring HTTP services. We reach for BoringSSL before we reach for a bespoke crypto library.
This is not conservatism for its own sake. It is a deliberate choice with three specific payoffs.
Hiring
The most expensive decision in any engineering organisation is the decision to learn a new stack. Boring technology is a hiring multiplier: the pool of people who can competently operate, debug, and extend a Postgres-backed Java service is orders of magnitude larger than the pool of people who can do the same with whatever was trending on Hacker News eighteen months ago.
The difference does not matter on day one. It matters in year four, when the person you hired to run the system needs a replacement.
Debuggability
When boring technology breaks, the exact same failure has probably happened to ten thousand other teams. There is a Stack Overflow answer. There is a blog post. There is a mailing list thread from 2011 with a patch attached.
When a fashionable piece of technology breaks in a subtle way, you might be the first person to hit it. You are now part-time maintainer of a project you did not sign up for.
In production, this asymmetry is brutal. At 3 AM, “google the error message and find the answer in forty seconds” is a life-quality feature.
Composability
Older tools have had longer to develop good edges. Unix utilities, SQL, HTTP, JSON — they interoperate cleanly because they have had decades to work out the kinks. Fashionable tools often bring their own world: their own serialisation format, their own auth, their own everything.
Composing boring tools is almost always cheaper than trying to fit a new one into an existing system.
When we break the rule
We do break it. The rule is a default, not a dogma.
The rough test: we will pick the less-boring option if all three of the following are true.
- There is a clear, measurable advantage. Not a blog post. Not a conference talk. A specific property of the work at hand that the new tool makes measurably easier.
- We are willing to be maintainers of the tool, not just users. If it breaks in an uncommon way, can we read the source, file a meaningful bug report, propose a fix?
- The failure mode is acceptable. If the tool is abandoned in three years, what does it cost us to migrate off it?
When those three conditions are met, we will happily adopt something new. When they are not, we reach for what has been around longer than most of our engineers have been writing code.
The dullness is the point.