Boring Is a Feature

What does boring look like in the age of AI? And I’m not talking about uninteresting. I’m talking about highly maintainable.

JavaScript?

I mean I guess models are good at it. Everybody knows it. It runs everywhere. The biggest problem with JavaScript is that TypeScript is better.

Certainly it’s better than picking a novelty language that you haven’t built anything with before. Does anybody on the team actually know Haskell? And how long ago did they know Haskell? You need to evaluate the cost of adopting it just as you would evaluate how long it would take to learn it and train the team on it.

The upfront cost can be easier to measure. But the recurring ones are much harder to predict. What happens when a maintainer moves on from a package that everyone uses, and the speed it takes to find a new maintainer is not as fast as you need it to be?

Boring tools are ones where the recurring cost of maintenance is as close to zero as you can get it. If you come back to it in eight months, it should work the way you remember it. This is a fairy tale that we tell ourselves, that nothing ever changes and we can control that change.

Is boring even possible in the age of AI, when it feels like everyone has their own particle beam cannon that they can point at your codebase?

I think it’s worth talking about what I mean by boring, because it can be used as a synonym for old, but that’s not what I mean. Boring means predictability.

Take all your npm packages. Can you answer these questions about all of them? Probably not.

  • How often do the release notes contain the word “breaking”? Skim a year of them. This is the single best signal available and it takes ten minutes.
  • How many people can merge? One is a risk regardless of how good that one person is. People change jobs, burn out, and lose interest.
  • What happens to old versions? A project that supports the previous major for a while is telling you something about how it thinks about your time.
  • Can you read the source? Not all of it. Enough to fix something yourself when you’re blocked and nobody’s answering.

Learn the new tool. Experiment. Try new things. Stay passionate about software. Just because you can use the new thing doesn’t mean you should.

Don’t always pick the boring option, just like you don’t always pick the new option. It takes wisdom to know what the right answer is.

You have to understand your failure modes, and when it’s an appropriate time to take a risk, and the scale of the risk.

Pick boring for the parts you don’t want to think about. Save the interesting decisions for the places where being interesting is the point.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

DevOps Developer-tools Software-development Engineering Tooling