Software Rot, Part 2 – What Maintenance Looks Like

Software applications (like homes, cars, and nearly everything else) need maintenance. Even when the software itself doesn’t change, the systems/devices it runs on and the larger software environment are always moving forward. This is called Software Rot.

Most software maintenance falls into one of these categories:

  1. Updating Dependencies – Upating the frameworks, libraries, etc. that your software uses to their latest and most secure versions.
  2. Version Support – Updating your application to support the latest versions of the platforms it interacts with (i.e., upgrading from Windows 7 to 10 or supporting the latest iOS).
  3. Project-Specific Improvements – Other updates and tweaks you’d like to make to improve your user’s experience with the software.

These items, all taken together, will tame most kinds of software rot. There’s also a ton of value in the small updates and learning that you get from coming back to a project and working on it after the world has advanced another year.

## How Often to Do Maintenance

It’s a balance. You want to do maintenance frequently enough to not fall behind. Once your old version of a tool won’t run anymore, it becomes much harder to work on. However, if you stop to do upgrades and other maintenance too often, you’ll spend more time dealing with updates than building features for your users.

Here are a few things we watch for:

* Major framework version changes. For example, Ruby on Rails only supports the two most recent versions of their software. When they release version 6, you should feel “on notice” that you have limited time before you’ll be forced to upgrade from version 5.
* Operating system changes. A new version of OSX or iOS will often change many things, such as API changes or new privacy restrictions on things like location services. When Apple (or Microsoft, or whoever) releases a new beta, you should start to figure out when you’re going to at least test it out.
* New versions of compilers and other direct project tooling changes. Changes to compilers and tooling can break compatibility with other third-party libraries you may be using — often in ways that are hard to predict.

Whenever I see any of the above, I’d definitely start planning when I’m going to make updates.

One thing I would not pay much attention to is version updates to random third-party libraries. A modern software project has so many small, third-party utilities that it’s not really feasible to track them by hand and evaluate each one.

In general, I’d recommend “annually” as a good maintenance cadence for just about everyone.

## How to Budget for Maintenance
There’s no hard and fast rule for what number to put in your budget for any given update. But there are some factors we can look at:

First, I don’t feel like it usually makes sense to budget for less than two weeks, no matter the project size. Here’s how that time might get split up:

* A day or two just getting the developer’s machine set with a dev environment, getting tests running, etc.
* A day to evaluate what needs to be upgraded: major frameworks, critical third-party libraries, etc.
* Two to Five days to work through whatever upgrade processes apply.

Beyond that starting point, I’d look at the amount that’s been invested in the project so far. Take some small fraction of that; a few percent might be a good starting point. The bigger the codebase, the more dependencies there are to update and test, and the greater the chance that an update could cause problems somewhere else in the codebase.

## Put it in the Plan
The what and how much are very hard to predict because, typically, you’re dealing with things that your team didn’t build and doesn’t know intimately. But that doesn’t make it less important. Get maintenance on the schedule, regularly.

You’re going to pay for the maintenance eventually. Make sure it’s on your terms.