There's a specific kind of excitement on an engineering team when someone suggests a new database. The demos look great. The benchmarks are stunning. Someone has a blog post about how it scaled to a billion writes. For about a week, it feels like the answer to every problem you have.
I've learned to be suspicious of that feeling.
Most of the systems I've built that are still running, still boring, still not paging anyone at 3am, sit on technology that was already old when I picked it. Postgres. A plain job queue. A monolith that does one thing. None of it is interesting. All of it works.
The cost nobody prices in
Every new tool comes with a bill you don't see at selection time. Not the license. The knowledge.
When you pick Postgres, you inherit twenty years of Stack Overflow answers, battle-tested backup tools, and the fact that every engineer you hire has probably used it. When you pick the exciting new database, you inherit its documentation, its Discord channel, and whatever three people on earth have hit your exact edge case.
The first time that new tool fails in production, you aren't debugging a problem. You're debugging a problem nobody has written about yet. That's a lonely place to be at 2am with a customer waiting.
I've lived that night. A queue library we picked for its throughput numbers started dropping jobs under a burst pattern we hadn't tested. There was no Stack Overflow answer, no known fix, just us reading library source at midnight while orders piled up. The boring queue we replaced it with was slower on paper and has never once done that.
Boring means predictable, not bad
People hear 'boring technology' and assume I'm arguing against learning or against quality. I'm not. Boring means the failure modes are known. When something breaks, the path from symptom to cause is short, because someone has walked it before.
I want my interesting problems to be the actual product, the thing customers pay for. I don't want my interesting problems to be why our message broker loses data under one specific load. That's not the problem I'm trying to be good at.
At Shanti Infosoft we keep a rough rule: you get a small budget of novelty per project. Spend it on the part that's actually your differentiator, and buy everything else off the shelf, old and proven.
When new is the right call
This isn't a blanket no. Sometimes the boring option genuinely can't do the job, and the new tool solves a problem you have today, in production, not one you're imagining for a scale you haven't reached.
The test I use is simple. I have to be able to name the specific thing the old technology can't do for us right now. If that's a real, measurable limit we're hitting, we evaluate the new thing seriously. If it's 'it would be cleaner' or 'it's more modern,' that isn't a reason. That's a feeling.
Choosing boring is a discipline, not a limitation. It's a bet that your time is better spent on the problem only you can solve than on rediscovering why mature tools got mature.
The best compliment I can give infrastructure is that I forgot it was there. It just ran, for a year. Boring technology is how you earn that.
For the flip side of this, we wrote about how the build-vs-buy line keeps moving: most 'let's build our own' calls are novelty wearing a business case.
When you last reached for a shiny tool, was it solving a problem you actually had, or one you hoped to have?
Top comments (0)