Pete McBreen's Position paper

Maintenance is the normal state of most commercial software systems. The initial system development activities are an anomaly in that the system is not running while these activities are taking place. Once we ship and the system goes live we are in Maintenance until we replace that system.

Therefore I make the claim that "Maintenance is the most important phase in the life of a software system".

Priorities change during maintenance. Timescales are much shorter. When a valuable production system is down, the team has to be able to diagnose and repair really quickly. Similarly, when a business change is identified that needs a system change, the time to change is typically measured in days or weeks, not months or years as is typical during initial development.

I make these claims from a background of 8 years working with Manufacturing systems (in the 1980's) and the last 5 years observing (and assisting) with the evolution of a stock exchange system. These were developed in a variety of languages, but many of the lessons are the same. I can remember one conversation that points to the difference between a maintenance and development mindset (This was in a component written in C). "Q: How long is a UserId? A: UserIdLen. Q: No, how long is it really? A: It's UserIdLen bytes long, I don't know how many bytes that is." Eventually to satisfy curiousity we looked up the actual value in the header file, but the entire system has been designed without any embedded numerical constants, all of the field lengths are defined in one header file.

Lessons learned

• Documentation is only useful to the extent that it shortens the learning time for new team members. When the system is down, there isn't time to search the documentation, the team has to really know how the system works.
• Given enough calendar time, any technology changes, so wrapper every bit of technology. Operating systems are particularly bad in this regard, because at some point your hardware will become obsolete and you will need to move to a new platform.
• Encapsulate all design decisions, the business assumptions will also change over time.
• It is OK to completely rewrite the application as long as it still runs while you change it. Evolving the code is an effective way of getting new team members up to speed.
• The domain and application knowledge in the team members heads is extremely valuable. The domain knowledge is crucial for designers.

Surprising observations

• CASE tools and Notations have had no impact (they were not used by either system except as a snapshot picture for review or marketing purposes). Every CASE tool bought eventually became shelfware.
• None of the "big-name" Methodologies were used but despite that the systems shipped, were profitable and were sold to many customers - a big test of usability and they were enhanced for years (the Stock Exchange system is still evolving very successfully)

Design for Maintenance

• Loose coupling is the way to go. Tightly coupled systems are a pain because a change ripples throughout the system and you cannot get a fast turnaround on changes.
• OO implementations help, but require much more expertise.
• Testability is a key design consideration. Luckily with Objects good testing frameworks like JUnit exist.
• Getting something small running early in the life of a project is extremely useful.
• Designers need to think about how maintenance releases can be made. Can small executables be released or does the entire monolith have to be reinstalled?
• Learning is the rate limiting step for development. It is easier to learn when there is a running system to experiment on than by doing what-if scenarios against design documents.
• Commercial systems last much longer than the developers think they will.
• Commercial systems change much more than developers think they will, successful systems are subject to numerous change requests over the life of the system, many of them "completely off the wall" compared to the original system vision.
• The developers have no clue about which parts of the system will be the most valuable or will evolve the most (value and evolution are closely linked for the systems I've worked on).
• Socializing the design is more important than documenting the design.

Teams can design for maintenance, but current methodologies do not help very much.

Incremental development seems to be an essential part of design for maintenance. That way the team gets practice at dealing with new and changing requirements. This is why I now prefer incremental requirements capture, it allows the team to experience requirements surprises so that they do not build in too many assumptions. With a process that captures all of the requirements up front, the team (think they) know all of the requirements and hence make brittle assumptions. Object technology helps, but it is very easy to assume something that isn't so (or more likely has changed by the time you get to work on it).

Pete McBreen, 27-Sept-1999

To participate in this workshop please read the Call for Participation