Software Evolution and Maintenance

So, you’ve just completed the launch of a new piece of software, Congratulations! Time to kick back and celebrate – you’ve earned it. Perhaps that’s the end of it and your program will stay as it is until it retires. However, there’s a good chance the maintenance phase has just begun.

It’s often said the only constant is change and software is no exception – even the constants declared in your code aren’t safe. This is perfectly natural. Software will grow over time, with new features.

It could be that one feature set aside early on as a nice-to-have, returns for Phase 2, an unusual bug requires an urgent hotfix post-launch, the edge case that wasn’t considered until one day someone produced a scenario with unique circumstances (users won’t appreciate having to provide something other than their legal name to get access to a public government service, for example – flexible validation might be key here), the list goes on.

Software Evolution and Maintenance

During the maintenance of software, one might expect to deal with a variety of different changes and an equally various number of reasons to change. There are four categories defined by ISO/IEC 14764 and while they can be broken down further, are a good point of reference:

• Corrective maintenance: reactive modification of a software product performed after delivery to correct discovered problems.
• Adaptive maintenance: modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.
• Perfective maintenance: modification of a software product after delivery to improve performance or maintainability.
• Preventive maintenance: modification of a software product after delivery to detect and correct latent faults in the software product before becoming effective faults.

Maintenance done before release is also a category, though perhaps a form of Preventive. Looking at the four main types, would it be preferable for maintenance to be a particular type?

Corrective would seem to be the least desirable, though perhaps the most important. When a defect is found, particularly by the users, the longer it remains unfixed, the less trust users will have in the software. The life expectancy of the software may be prematurely shortened if the user base disappears overnight. Good Preventive maintenance should help to counteract this.

As software continues to be used, Adaptive and Perfective maintenance seems like an inevitability. Discussions around what kinds of functionality could be included to improve value will arise. Perhaps a feature is adjusted to allow for more flexibility (i.e. a PDF uploader being altered to allow images and Word documents). This maintenance helps to keep software alive, allowing it to continue to serve the user base and grow alongside their needs.

Knowing what these forms of maintenance are is all well and good, but what do we do with this information?

It’s possible to use this knowledge to assess your own codebases and figure out what has been happening over time – a kind of health check, if you will. This does require some disciplined version control strategies to make the most of, however. Keeping commits clean and focused (i.e., addressing one thing per commit) will help.

Look at each commit and identify what kind of change occurred. If your team provides descriptive commit messages, that’s even better. If your commit messages refer to additional functionality as opposed to frequently fixing problems that might be a good sign of healthy growth.

There’s a fun little tool you can use if you want a quick visual representation of the most recent set of commits called ‘Commit Cloud’. The demo works with public repositories, but the basic theory behind the code could be applied to a local repository if your code is kept somewhere secure. Using the demo here, try it out on a public repo of your choice. It will create a word cloud of the last 100 commits. If your commits are reasonably descriptive, you might start to see patterns emerge and get a feel for where the repository has been going recently.

It is rare for software to remain unchanged after launch. There are good and bad reasons for software to change, but with tools like these, we can make it easier to understand why these changes happen. With better insight, more informed decisions can be made.

‍If you’re thinking about evolving or maintaining your software, we’re here to help. Fill out our simple Contact Us form today and let’s start the conversation.