Guidelines for Maintaining a Software Product

So, you are a successful and competent software developer, and you are given for first opportunity to lead a project. Unfortunately it is not a 'green field' project, you've taken over the maintenance of someone else's project. What can you do make sure you do a good job, but keep the administration overhead low?

Here are some practical observations that you may find helpful:

• If you don't have a source control system, get one that suits your team size and budget (eg. Subversion, Visual Source Safe, Visual Studio Team System).
• Consider having two main branches in your source control tree:
• Active development (new features / major enhancements)
• Maintenance (defect fixes / minor enhancements and optimisations)
• Make sure you label each release.  This allows you to produce hotfixes for a known code base.
• Maintain a backlog of pending minor enhancements to be scheduled as resource becomes available.  Record which release has the minor enhancement.
• Adopt an issue tracking and ticketing system.  Regularly reviewing this will highlight usability issues which UI refinements could alleviate.  This may also provide a useful source of ideas for system enhancements.  This should also be to provide you with information about the overall health of the system at a glance.  Is the defect count going up or down?
• Create a searchable knowledge base for the support team, and keep it up to date.  This should contain the following:
• Core features and how to use them
• Currently known issues, their scheduled fix date, and any known work-arounds for them.
• A trouble shooting guide and checklist.
• When upgrading the system, consider the upgrade path for existing data. Pay particular attention for how you will handle data which was 'clean' but will now be 'dirty' as a result of the upgrade.
• Create and communicate a schedule of releases so the support team know what to expect and when.  Accompany each release with a document (in whatever form) outlining what the system changes in the release are. Tailor this document to the recipients (probably your project sponsor and other key stakeholders).  Make sure you have a mechanism for also communicating these changes to the support team and users.
• Automated testing frameworks are valuable assets.  Hopefully, the development team will already have a testing framework for both functional tests and user interface tests.  If they haven't, its time to find a good tool and put together a schedule for creating a test framework over time.  Especially once you enter a rapid resolve-test-release cycle, these will prove their weight in gold.  It is quite satisfying being able to run a battery of automated tests prior to release and have strong confidence that no regression errors have been introduced.
• Expectation management is key priority.