1 Comment

Software Rot, Part 1 — Why & How it Goes Bad

Software rots if not maintained. The longer it sits on the shelf, the harder it becomes to work on it. It may even stop working on its own one day.

This surprises my clients frequently, so I wanted to talk a bit about why this happens and how to plan for it.

The World Moves On

Let’s take a look at an example from literature:

Bifil that in that seson, on a day,
In Southwerk at the Tabard as I lay
Redy to wenden on my pilgrymage
To Caunterbury with ful devout corage,
At nyght was come into that hostelrye
Wel nyne and twenty in a compaignye
Of sondry folk, by aventure yfalle
In felaweshipe, and pilgrimes were they alle,
That toward Caunterbury wolden ryde.

That’s a bit opaque, isn’t it? It comes from the introduction to Chaucer’s Canturbury Tales in its original Middle English. You can compare it side-by-side with a contemporary translation here.

Even though this text hasn’t changed since it was written in the 1300s, it is hard to understand today because the rest of the world has kept changing.

How Software Rots

It’s the same with software: Your application may remain unchanged for many years, but the rest of the technology world keeps marching forward.

No product is built in isolation. Someone else built an interpreter for the language used in your app. Someone else built the processor on which it runs. Someone else created the protocol it uses to send data over the internet. Those things are all constantly evolving for a plethora of different reasons. Often, the changes are simply about fixing bugs and security holes, but they can also involve significant new features.

For example, Apple’s new operating system OSX Catalina finally dropped support for 32-bit applications[1]. “Software rot” (in this case) is when your application is 32-bit or uses a 32-bit component. It might be easy to upgrade, but it might not be.

Kinds of Software Rot

That’s one example of how things can start to fail over time. Here are a few different kinds of rot:

  • Obsolesence: Some third-party functionality is disappearing or changing, and your application needs to be updated to accommodate the change.
  • Upgrades: An upgrade to get a bug fix from a third-party library might pull in the next full release.
  • Platform or hosting changes: Hosting companies like Heroku may deprecate old services, so you can’t expect your app to work forever.
  • Institutional knowledge: If no one has worked on your app for years, there will be a ramp-in period as a new developer joins, even if nothing is wrong with the app.
  • Security: No one wants to write insecure software, but we often find errors after the fact and make new releases with fixes.

Don’t Let Things Rust

As your software ages, it will need maintenance to avoid the above problems. In my next post, I share recommendations for creating a smooth, predictable software maintenance schedule.


[1] Apple wanted to support 64-bit operation in order to allow applications to access more memory for things like better multimedia handling. This is a trade-off: They need to support both versions, or they break all 32-bit apps. For years, they did support both 32 and 64, and then for a while, 32-bit apps would pop up a warning dialog. Now, 32-bit apps have finally been killed off for good.