The newest stack is rarely the best choice

There's a reflex in our trade: as soon as a new framework comes along, everybody wants to use it. At the next conference it's on every slide, every job posting lists it as a requirement, and before you know it the technology you've been building with just fine for years suddenly feels like a deficit. I know that reflex, I have it myself.

But I go along with it less and less. Not because I don't get new things or don't like them; I do. It's because I've seen who pays the bill when you pick your stack for what's hot this season instead of for what's still running in five years.

The stack of the season

Let me give the beast a name. I call it the stack of the season: the collection of tools getting the most applause right now, regardless of whether your project has any use for them.

Why do we choose it? Rarely because the client asks for it. Usually for something else:

• The résumé. There's a reason colleagues call it résumé-driven development. A new framework on your profile is more attractive than "ten years of the same language, and I got really good at it". That's human, but it's your interest, not the client's.
• The fear of falling behind. Nobody wants to be the builder who "still" uses X. So you reach for the new thing, if only to look modern.
• The demo. The new stuff demos fantastically; in half an hour there's something shiny. What you don't see in that demo is how it holds up three years from now.

The sting is that the costs only land much later, and on a different table than where the choice was made.

Who gets the bill

New frameworks often run out of breath fast. This year's exciting project is, in three years, the abandoned GitHub repo whose last commit is a year old. Breaking changes pile up, the documentation lags, and the handful of people who really knew it have moved on to the next shiny thing.

The client notices none of that at first. It runs, it looks good, everyone's happy. Until it needs maintenance, and it turns out there's barely anyone left who knows this stack, or wants to. What should have been a quiet update becomes a search, or half a rebuild.

That's the throwaway stack: built on something that impressed at build time and that nobody dares to touch at maintenance time. The client is stuck with a choice that was never made for them.

Why boring wins

Opposite the stack of the season stands tooling that has simply been doing its job for years. Not exciting. Well documented, widely supported, and so long-lived that in five years you'll still find someone who knows it.

Boring means something very concrete here:

• The tool has been around long enough that the sharp edges are worn off and the pitfalls are known.
• A large group of people can work with it, so your client is never stuck with a single builder.
• What you write today still runs next year, without a forced upgrade turning everything over.
• It's testable, readable and transferable; also to me two years from now, who has forgotten how it all worked.

This is the same rule that runs through all my work: the unpredictable part belongs behind a tight boundary, and the rest is allowed to be boring and predictable. Boring code isn't a lack of ambition. It's the ambition moved to where it counts: the client's problem, not the wiring around it.

New isn't forbidden

Now the honest nuance, because this isn't a plea to build everything like it's 2010.

Sometimes a new tool really is better. Faster, safer, or it solves a problem the old one couldn't. Then I use it, gladly. The difference isn't new versus old; it's in the question you ask before choosing.

That question is simple: does this choice serve the client in five years, or does it serve my résumé today? A new technology that's mature enough, has a lively community and solves a problem you really have is a fine choice. That same technology picked because it happens to be in fashion is a risk you're handing to someone else.

So I don't pick old over new. I pick proven over trendy, and I never let the client be the guinea pig for something I just felt like trying.

What you can expect

Are you afraid of a throwaway stack, of a system that nobody dares to open in a few years? Rightly so. But that's exactly what boring tools prevent.

For me the excitement isn't in the tools. It's in something that keeps working: software you can still just switch on in five years, that you can find a builder for, and that grows with you without every step being a gamble. The stack of the season will be gone in a season. I'd rather build something you're still happy with then.