Software Maintenance Best Practices
In the last post we looked at the 4 types of software maintenance. In this post we are going to look at some best practices that actually save time and money in the long run. Our software maintenance best practices are:
- User Training
- Regular Maintenance
Testing is a critical part of software development. The idea behind testing is simple enough to understand, it is there to stop issues in the software reaching live code. We will probably cover testing in more detail in another post but from the development point of view there are a couple of well used methods of testing:
Although this can be prone to human error, with a good testing plan it can be very effective. It is probably best suited to simpler software but is also used frequently in new projects with the idea that the second type of testing, below, will be implemented at a later date.
This has a huge speed advantage over manual testing but is heavily dependant on both the quality of the tests written and the coverage (how much the software is tested). The big disadvantage is that they take time and money to set up in the first place. There is no hard and fast rule but automated testing for 75% coverage of the software will easily add 30% to the development time. It is nearly always worth it in the long run though.
Automated testing sounds like the best practice but in reality, it is very difficult to get to above 90% coverage in all but the simplest applications. Therefore, a combination of manual and automated testing normally strikes the right balance for both coverage and cost to implement.
Always up to date technical documentation for the software application can have a huge impact on both maintenance and new feature development. Developers are often working on multiple projects; new developers join the team and others leave. The role of the technical documentation is to bring someone up to speed on the software without having to spend hours going through lines of code to work it out. In fact, there are more than just developers that need to know how the application works and they probably can’t even read code.
Good documentation will cover everything from the development stack through to more specific details about how and why the software does what it does. It should include system architecture diagrams, brand guidelines, test plans and details of what automated tests cover, the regular maintenance plan, release processes and so much more. Of course, this is changing all the time so it also needs to be regularly updated. A lot of development environments now include a wiki style feature that allows this all to be kept with the code of the software and updated as changes are made.
This is not training the user how to use the software. This is training the users how to report an issue. The goal is that they report the issue in enough detail so that the issue can be replicated before being fixed. It doesn’t have to be complex, just a quick guide into what makes up a great bug report.
You may have thought that regular maintenance would have been top of our list rather than at the bottom. The reason we put it last is that it includes a lot of what we have covered above, it is not just working on the code itself.
The trick to regular maintenance is to have a checklist to work through at pre-determined intervals. On smaller software applications you might have one checklist that you do on a monthly basis. On larger applications you might have several checklists, for example a weekly list, a monthly and an annual list.
Here are a few things we would include on our recommended plan:
On a regular basis you should check that the backups you are expecting to be created are being created. Modern backup procedures should notify you when something has gone wrong. This doesn’t mean no manual checks should be made but it does mean this can be done very quickly.
At least once a year you should check that you can restore a backup.
With every release, especially when new features are added, you should make sure the backup is still covering everything you need it to do.
We covered this in our previous post. Basically, this is updating the complete software environment and making any changes to the software to keep it working as the rest of the environment changes.
All new features and corrective maintenance will probably need the testing plan, covered above, modified and extended.
The technical documentation should be updated on a regular basis in line with the above.
Hopefully you are already at least doing some of the above but don’t worry if you are not. All of them can be implemented at any stage and the most important takeaway should be that getting them in place will be more that worth the work involved. If you need help in implementing any of the above then please get in touch.