You’ve made a big investment in creating a custom software package, but just because you’ve finished the feature work doesn’t mean the work is “done.” You want it to last for years to come. That means software project maintenance.
When you put together your budgets for these big custom software development projects, don’t forget that, in addition to the initial investment, you must budget for ongoing hosting and maintenance costs.
Your software doesn’t exist in a vacuum. Instead, it’s within a sophisticated ecosystem of devices (such as the phone or computer you might be reading this post on right now), browsers (ditto), and other less-visible foundations. Even if your software is “done,” it runs on a platform by Apple, Microsoft, or other vendors — and those platforms aren’t finished changing.
Your software’s platform will evolve in many ways over time.
One of the most important ways is security. Researchers and vendors are constantly seeking to understand how things can fail.
These findings can range from easily-avoidable errors in how your framework is used to insidious bugs in the physical hardware your system runs on. And, that’s what makes them hard to prevent up-front.
We won’t choose a known-insecure package to integrate with, but we discover new vulnerabilities constantly. The safest approach is to patch your dependencies regularly.
If you host your application yourself, you probably won’t be forced to upgrade frameworks (though you should). But if you’re in an app store, such as Apple’s iOS App Store or Google’s Play Store, you’re going to be forced to do basic maintenance.
Normally, this isn’t a big deal. This might require your app to simply update its metadata (data like name, description, and icon) to include privacy data. But this also can be a bigger change. Apple’s iOS 7 was a notoriously difficult upgrade for iOS developers because of how much Apple changed the operating system.
If you want end-users to be able to use your app, you’re subject to the whims of their platform vendors. Plan to spend some time every year checking the latest betas and making sure everything works as expected before Apple kicks you out of the app store.
One last major reason to do software project maintenance is simply to ensure that someone can jump into the codebase at a moment’s notice to make a critical change.
This could be as simple as maintaining institutional knowledge by ensuring there’s always an employee familiar with the code. It shouldn’t be surprising that it can be hard to complete feature or bugfix work quickly in a codebase one has never seen before.
It goes beyond that, though, to software and hardware. For example, I am writing this on an older, Intel-based MacBook. If I were to spill a glass of water on it (knock on wood — I have actually done that before!) then I wouldn’t be able to get an identical replacement. A new MacBook would be on an M1 processor. That might not be a problem for a given project, but it could potentially mean making a lot of software changes just to make the thing run.
An example of this is standards for nuts and bolts. Some cars used different sizes and thread pitches. While your mechanic can likely still work on a vintage car, they are more likely to require a trip to the hardware store (and the extra time that entails.)
In software, this is also possible to work around. You can update custom software, and there are VMs and compatibility layers. But if a user in the field can’t use your product, there’s a big difference between “I’m working on a fix now” and “Let me set up a development environment for that package, and I’ll let you know what I find next week.”
How often should you plan for maintenance work?
The simplest rule of thumb is to do major software project maintenance annually. It’s not a bad cadence for most projects.
Going beyond that, here are some more rules of thumb that you might factor into it:
1. Look at your ecosystem’s release cycles. If you have an iOS app (for example,) then you should at least look at it every time Apple makes a new release. Similarly, you should update a web app based on Ruby on Rails periodically as Rails gets updated. Staying on a supported LTS will ensure that if a new vulnerability is discovered that you’ll be able to get it patched without major effort.
2. Look at your industry’s risks. If you deal with HIPPA data or otherwise have regulatory/statutory concerns, you should be more concerned and plan for commensurately more frequent and bigger investments. If your data is lower-risk, then you can probably push your maintenance cycle out a bit.
Finally — how much should you budget for maintenance?
At a minimum, I recommend no less than one week for almost any application. It simply takes time to get your bearings in the codebase after setting it aside for a long time. It also it takes time to test and verify that the updates haven’t broken anything. For apps that don’t need a lot of work, a week could be enough to upgrade a few packages, fix a couple of issues, and deploy.
For more complex apps, it’s reasonable to allocate somewhere between 5% and 10% of your initial investment each year. You won’t always use it all, but a) it’ll give you a ballpark number, and b) in some years, you will probably use more than the amount allotted.
If you want your project to be around for years and years, don’t forget about it. Be sure to take a regular look at it to ensure that software stays secure and available, and ensure your team can quickly adapt to changing business and technology needs. It doesn’t need to be a big investment, but if you don’t make that investment regularly, you might be in for a big surprise instead.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
