Kurt W Derr's Position paper
This is just one possible goal of design. Designs should always satisfy user
requirements. If they don't, the software product won't be used or purchased.
Maintainability and other goals such as time to market, reusability, robustness,
portability, scalability, extensibility, testability, and/or adaptability should
be project goals. It is not possible to optimize all of these at once.
A system enters into maintenance after it is deployed. Architecture, which is a major issue during the initial development of the system, is less of an issue once the system has been deployed. During maintenance, programmers update a system to meet new customer requirements and fix lingering bugs. The architecture needs to be well documented so that the maintenance team can easily understand the elements of the system and where changes need to be applied. The design and code reviews, which hopefully took place during the initial development of the system, should continue during the maintenance phase. This helps to keep all team members current with the design as the software team changes over the life of the system.
The better software projects establish a software process and guidelines for software development at the beginning of the project. The process specifies the general steps that the project will go through and what the deliverables will be for each step. The guidelines include design and coding standards and the use of design and code walkthroughs. These decisions all affect the life of a system. A disciplined environment enables creativity by freeing the most talented software professionals from the many crises that others have created. A disciplined environment also enables higher quality software to be developed in a shorter period of time.
A key issue in design and maintenance is how far is your customer/project manager willing to go; i.e., what are they willing to pay for? Will they pay for the extra time and effort that is required by proper design, walkthroughs, documentation, and testing?
The up front strategic decisions made by the project impact development and maintenance prior to any design work. For example, the use of a relational database versus an object database with an object-oriented programming language, for an application with a complex object model, generally implies more code (code that translates between objects and tables). An object database that has provisions for easily inspecting the persistent objects that are part of the system can help to minimize the development and maintenance costs.
Non-OO projects may suffer from some of the same problems as OO projects. On several non-OO projects I have seen teams totally rewrite an individual's code when that person left the team. These projects generally had little documentation because of severe schedule stress, personnel lacking in analysis and design skills, no software process, and/or leadership problems.
On one non-OO client server project that I worked on I had to take on the role of software archeologist in order to discover the how the system worked. Again, there was very little documentation. And what documentation existed was inaccurate and out of date.
I have also had the opportunity to play software archeologist on OO projects as well. However, I believe that well designed and implemented OO systems are easier to maintain than non-object-oriented systems with the same qualities. The design and code reflect a more natural representation of the solution to the problem. The use of existing proven class libraries that cover a broad spectrum of programming capabilities (such as graphical user interface, streams or input/output, security, data structures, networking, distributed computing, mathematics, graphics), and are provided by a single vendor, are hard to duplicate in the non-object world.
The application of detailed statistics collection and reporting in a client server system greatly improves the testability and maintenance of the code. Tools that enable viewing of the statistics gathered on the server prove invaluable. Tools can make it much easier to determine what is causing a problem and make it easier to test and see the results.
In a Web-based client server information system, embedding diagnostics capability into both the client and server sides makes the system easier to maintain. Diagnostics capabilities include being able to turn on or off the viewing of serialized data sent from the server to the client, or visa versa. The client side diagnostics might display the contents of collections, mathematical calculations, state transition messages, and graphics data.
So what can we do to increase the economic life of a system with the application of a reasonable amount of resources?
1. Recognize that maintenance is just one possible goal of design. It is doubtful that all goals can be optimized at once. What design goals are most important to your project and what will your project manager pay for?
2. Keep the architecture and design of the system documented. Ensure that all maintenance team members understand the design to a certain degree of detail.
3. Establish and follow a software process that includes specific deliverables and practices; e.g., design and coding standards and walkthroughs, application of heuristics and patterns.
4. Be cognizant of the impact of strategic decisions on the maintenance of the software. Some tools will make the maintenance job easier than others.
5. Depending upon the application, develop detailed statistics collection and reporting to improve the ability to diagnose problems and view test results.
To participate in this workshop please read the Call for Participation