In praise of boring technology
There is a quiet pressure in software to use the newest thing. New frameworks, new databases, new paradigms arrive constantly, each promising to make everything faster and cleaner. We are not immune to the appeal, but over the years we have come to a firm conclusion: for almost everything that matters, boring technology wins. Here is why we reach for the well-worn tool first.
Boring means understood
A technology that has been around for a decade has been used, broken, and fixed by an enormous number of people. Its sharp edges are documented. When something goes wrong at three in the morning, the chances are overwhelming that someone has hit the same problem before and written down the answer. Newer technology, however elegant, has none of this accumulated knowledge. You become the person discovering the sharp edges, often at the worst possible time.
Boring means predictable failure
Everything fails eventually; the question is whether it fails in ways you can anticipate and handle. Mature tools fail predictably, because their failure modes are well charted. You know how a long-established database behaves under load, what happens when it runs out of disk, how it recovers from a crash. A newer alternative might be faster on a good day, but you have far less idea what it does on a bad one — and bad days are exactly when predictability is worth most.
Novelty is a cost you pay in surprises. Spend it deliberately, on the few problems where it actually buys you something.
You have a limited budget for novelty
This is the idea that changed how we make these decisions. Every project can absorb only so much novelty before the risk becomes unmanageable. Think of it as a budget. If you spend it on a new database, a new language, a new deployment model, and a new framework all at once, you have no margin left when one of them misbehaves — and something always does. We try to spend that budget on the one or two places where a newer tool genuinely solves a problem the old ones cannot, and to keep everything else reassuringly conventional.
The hiring and handover argument
Boring technology is also easier for people to join. When a system is built on widely-known tools, a new engineer can be productive quickly, because they probably already know most of the stack. When it is built on an exotic combination, every new person faces a long, expensive climb, and you have shrunk the pool of people who can help you. The same applies when we hand a project over to a client's own team: a conventional stack is a gift, an unusual one is a burden.
When new is the right call
None of this means freezing in the past. Sometimes a newer tool really is the right answer — when it solves a problem that the established options simply cannot, or when the established option has become a genuine bottleneck rather than merely an unfashionable one. The point is not to refuse novelty; it is to demand that it justify itself. We ask what specific problem the new thing solves, what it will cost us in unfamiliarity, and whether that trade is worth it. Often it is not. Occasionally it clearly is, and then we adopt it gladly.
Boring on the outside, sharp on the inside
The reward for all this restraint is that we get to be adventurous where it counts. Because our foundations are stable and predictable, we can spend our creativity on the actual problem the client is paying us to solve, rather than on fighting our own tools. Boring technology is not a lack of ambition. It is what frees you to put your ambition where it belongs.
Written by the Arcwell engineering team. If you're wrestling with something similar, we're happy to compare notes.