Planning for Software Maintenance: How to Prevent “Old Software”

Many first time software buyers don’t know to consider software maintenance when planning their annual budgets. This shortsightedness is understandable—software is expensive to build and most dev shops don’t want to spend a lot of time on long tail cost curves. It can also be difficult to convince buyers to continue spending more money on products after the final invoice is paid. So, why should product owners anticipate additional costs down the line?

Simply put, just because your product is working as expected does not mean that it will continue to work in the future. Browsers and operating systems are continuously releasing new versions, and it is difficult (if not impossible) to anticipate what methods in your app might deprecate or what third-party plugins will become incompatible once development has stopped. Take a look at Adobe Flash and mobile devices as one pertinent example—neither Apple nor Android devices support Flash anymore. In the browser world, we can look to Chrome and Firefox for the 6 week release cycle on new point versions. Technology is in a perpetual state of accelerating evolution with no slowdown in sight. With that in mind, it makes sense that an application should never be considered “finished.”

Customers can generally take two routes when approaching the long-term lifespan of their products:

1. They can invest in annual maintenance to make sure the product code is current. This is often referred to as Preventative Maintenance.
2. They can use the product for as long as possible without making significant updates to the code with the expectation that they will need to build a completely new system sometime in the future (typically after a few years).

Think of it like buying a house: either the owner invests money annually to make sure that the roof is repaired or replaced before there is major damage, the water-stained ceilings gets fixed, and the hardwood floors get refinished, or he decides against repairs until the house is condemned, and he need to knock it down and build a new one. Either way, the homeowner spends about the same amount of money—it just depends whether he prefers to spread it out or pay in one large lump sum. When it comes to software, there is no right or wrong answer here, as long as the customer plans for either scenario.

Assuming Option 1 is chosen, how much should he put money aside to maintain his product? Our recommendation is typically an allocation of 12-15% of the original project budget toward yearly maintenance. This amount should be plenty to ensure that both the code and third party plugins are up-to-date and effective for the business environment. This sort of maintenance should not be confused with Corrective or Enhancement/Adaptive Maintenance which is to either fix defects or add features. Often this Preventative Maintenance is deferred for 1 to 2 years and then bundled up to make a larger update to the system.

What happens if a buyer does not plan for either option? Unfortunately, this approach rarely ends up working well. The lacking preventative overhead forms into a debt often called a tech debt. This “tech debt” has to be paid at some point and often if not careful it’s years later right when you are ready to scrap the solution and start over. We worked with one company that learned this lesson the hard way. They spent 300k on an iOS app for both the iPhone and iPad. Based on the logic above, they should have either allocated ~45k a year to keeping the code updated or planned for another ~300k project somewhere down the line. The original app was built for the iOS 4; the following year, the iOS 5 was released, which followed Apple’s model of a yearly OS release. We provided this customer with a list of suggested updates, but they chose to use their yearly allocated budget to build new features instead. The same thing happened when the iOS 6 was released. Instead of addressing the accrued tech debts, they approved small visual updates to address the user experience. Yet again, they had only allocated enough of their yearly budget for us to put bandages on open wounds—short-term focus can often equal long-term problems.

When the iOS 7 rolled around, the app code looked like it was made out of duct tape. This OS update was too significant for the outdated code to handle. Both native and custom UI changes caused fundamental breaks in the experience and the overall architecture. Each software update that Apple released deprecated methods in the code and broke its functionality. The app even reached the point where it was impossible to submit to Apple because it did not function when compiled in the latest version of Xcode (which Apple requires in their submission guidelines). The customer had not budgeted 45k a year to make incremental updates, so, it goes without saying that they absolutely did not budget 300k to rebuild the entire app. It was, to say the least, a huge mess—but it was a mess that could have been easily avoided if the customer had gone into each year expecting to pay a certain amount on software upkeep or if they understood that a total rebuild would be imminent. Despite our objections, this customer did not prepare for either scenario. It cost them dearly.

It is imperative to understand that just like any other major purchase (a large appliance, a house, a car), software expenses do not go away once the project is technically completed—there are costs associated with preventative maintenance to ensure your original investment is not deteriorating over time. Before beginning a software project, it is important to consider the cost of maintaining the software. If it does not look like there will be budget available for yearly upkeep, then be sure to understand that a point will come when the current product is no longer usable. Anticipating future needs can prevent a lot of heartache down the road

Need help getting ongoing costs projected or need help looking at a project? Contact us below.