A Small Case for the Boring Stack
I work in Oracle APEX. For the uninitiated: it’s a low-code application development framework built on top of Oracle Database. It’s been around since 2004. The UI is not winning any design awards. The developer community is small relative to, say, React. Conference talks about it are rare at the kind of events I see covered on Hacker News.
I like working in it.
This is not a common thing to admit. But I’ve been thinking about why, and it connects to something I think is generally true about software choices.
What “Boring” Actually Means
“Boring technology” in the Dan McKinley sense isn’t technology that’s old or unglamorous. It’s technology you understand well enough that it doesn’t surprise you. Technology where the failure modes are known, documented, and recoverable.
APEX is boring in this sense. When something breaks, I usually know why. The documentation exists, it’s accurate, and it’s been refined over twenty years of production use. The Oracle optimizer has well-understood behaviour. The security model is established.
This matters more than people admit when they’re choosing frameworks.
The Cost of Novelty
Every framework you choose comes with a novelty tax. Time spent understanding its particular way of doing things. Bugs that haven’t been hit by enough people yet to be documented. Abstractions that looked clean in the demo but leak in ways that aren’t yet known.
The novelty tax can be worth paying. If a new tool gives you a genuine capability you couldn’t get otherwise, or if the team already knows it well, the math changes. But novelty for its own sake — because it’s new, because the talk at the conference was good, because someone’s LinkedIn post made it look simple — is expensive.
The Other Thing About Boring Stacks
When you’re not fighting your tools, you can focus on the problem. The problem is usually more interesting than the tooling anyway.
In APEX, the interesting problems are data modelling, query performance, workflow design — things that matter to users. In a newer framework you might spend that energy on build configuration, understanding SSR hydration edge cases, or debugging a dependency conflict.
I’m not saying APEX is the right choice for everything. It’s not. But the instinct to always reach for the newest thing is worth questioning, case by case.
The One Exception
The one place I think novelty is worth pursuing aggressively: your own learning. Learning new tools, new paradigms, new ways of thinking — that’s how you build judgment about when the boring choice is right and when it isn’t.
You can’t argue for the boring stack from ignorance. You have to know the alternatives well enough to choose deliberately. That requires some time in the uncomfortable new-thing space.
The goal isn’t to always use boring technology. It’s to make conscious choices. Boring and new both have costs. The mistake is defaulting to either without thinking.