The quiet power of boring technology
Engineering · 1 min read
The most useful question I ask before adopting a tool is simple: what problem does this remove?
Not what it makes possible in theory. Not how elegant the demo looks. What friction disappears from the work I actually do?
Familiarity is a feature
A familiar database has something a new one cannot offer on day one: a map of its failure modes. You know where to look when a query slows down. You know what a backup looks like and how to restore it.
That knowledge buys attention. Attention you can spend on the parts of your product that deserve invention.
Keep the moving parts visible
Start with one service, one database, and a deployment you can explain to a colleague. Add a queue when work genuinely needs to happen later. Split a service when its boundary has become obvious.
Complexity is easier to add than to take back.
Boring technology is not an argument against learning. It is an argument for choosing where you spend your uncertainty.
A small decision checklist
- Name the problem before naming the tool.
- Try the capability you already have.
- Write down the operational cost.
- Keep a way to reverse the decision.
Sometimes the new tool wins. Let it win on evidence.