Immutable Cheese

Or, Re-wording the Lessons of ‘Choose Boring Technology’

Here’s a question: What do you do when that “cool new” REST framework your company uses is dying on the vine? Someone hung every application off of it like a damn Christmas tree, and uh-oh, now it’s February.

Let us assume that summary execution is no longer an option, because the brilliant architect who made that decision has long since left. That aside, what are our options?

Typically the list looks something like:

  • Get the suits to sponsor the library’s development (haha, good one)
  • Find a spare dev who has time to maintain the library (haha, good one)
  • Pray that no major vulnerabilities are found (winner 😃👍)
    • Nobody moves, and nobody gets hurt

I’ll not disparage the author of the library for abandoning it. It’s a pretty little project, but they had other shit to do (and boy, don’t we all). I will, however, offer a comparison. An old project of ours, built long before that REST framework, depended on an older-still platform: Apache Tomcat.

The Apache Tomcat logo. It's a somewhat Picasson cat. Rather abstract.
      It could be said to look a bit 'dated'.
A logo like this means you're in for a treat.

New question: What do you do when you realize a project is on Tomcat 9.0.10, which released in mid 2018, and has 23 known vulnerabilities? Well, you probably update to tomcat 9.0.111, which released on Oct 14, 2025 and has no known vulnerabilities.

Despite being a full two major versions behind the latest, we’re still getting bugfixes without really even trying. Is Tomcat the same as a REST framework? Certainly not! Was its stability nonetheless enormously refreshing? Well, now you’re catching on.

Anyway, I don’t know. New technologies can be good, learning is good, progress is good. And there are certainly parts of our stack where I curse the heavens we didn’t choose something just a bit newer. Other times, I wish we hadn’t.

Really, I think I’ve grown wary of dependencies in general. I’m sick of projects breaking because the new version of a dependency depends on a new version of another dependency that’s actually incompatible with another dependency’s dependency. Get me outta here.

Or, could I use some hot new cli programs to clean up my ~/.shell_aliases? Or even just some special zsh features instead of doing everything the stupid bash way? 100%. And it might be less dangerous, depending on your context. But it’s also… hard to share? Part of the impetus for this rant is that I got sick of trying to share a script, and having to sheepishly tell people, “It works perfectly! Just please go ahead and install fzf and jq, if you haven’t already.” Great tools! Incredible tools! But sometimes I’d rather have the portability of POSIX.

And hey, there are absolutely things we don’t need to build again. Many problems are more complex or more low-level than I’m inclined to concern myself with day-to-day, but sometimes I just want something I know isn’t gonna change. I want sane defaults.

Most of the time, I don’t need a perfect system: I need one I know how to use.

    More Posts