Maintenance

A database application is rarely, if ever, completely finished. Foreseeing every potential scenario that may arise is nearly impossible, and as a result, bugs that did not come out during the testing phase may surface from time to time and will need to be fixed. Even the most arduous testing will not reveal 100 percent of the bugs that may be present. I have seen bugs surface weeks, months, and in some cases years, after the main work is completed. You may remember the infamous Y2K bug that took decades to discover.

Since members of the development team know the code structure best, they will most likely be the ones called upon to fix it. This also highlights the need for good documentation. Imagine going back to code months or years after the fact. Without adequate documentation, even within the code, a relatively easy fix could take a great deal of time.

An application is rarely a static endeavor. In addition to fixing bugs that may arise, you will be adding enhancements related to your clients’ needs and new technology. Many times a client’s needs may evolve over a period of time and, with it, the requirements of the application. New tasks may need to be performed, while existing tasks may need to be deleted or modified. I always tell students that once you have developed a database application, chances are that you will be living with it for the rest of your career.

Whatever the reason, resources for ongoing maintenance should be allocated at the beginning of the project and reviewed periodically.