Not many developers get the opportunity to be part of a project through the entire SDLC. For many people who are working on maintenance project, where the product is already there, the developer is usually involved only in bug-fixing or minor enhancements. Having been involved in a few, I have always wondered on the question, how can the Design Patterns be applied in such a scenario?

I raised this question to the authors of Head First Design Patterns at Javaranch and the following was Elisabeth’s reply:

..even if you are involved only in the maintenance of a project, programs continue to evolve and new requirements come along all the time. A maintenance person might end up being the “expert” on the code after a while, especially after it is gone through a number of fixes and upgrades. Perhaps this maintenance person can see when the bug fixes that are requested are going to cause a problem, or perhaps are caused by a bad design. Having design patterns around to help to see where a program needs to be made more flexible to meet changing requirements is good for anyone. And eventually, this maintenance person might be asked their opinion of whether or not the program needs an entire overhaul to support a new requirement, or if they think a new requirement can be fit into the existing code. Knowing and understanding the design will help them greatly with this challenge.

While I concur with her viewpoint, I maintain a level of skepticism regarding the practicality of applying Design Patterns to maintenance projects.

Often, these projects lack comprehensive documentation, making it challenging to discern the underlying architecture or employed patterns from the myriad of files typically present, numbering in the range of 2,000 to 3,000. Despite initial adherence to design patterns by application designers, the realities of resource rotation in maintenance projects can lead to a degradation of pattern adherence over time.

Moreover, with numerous hands touching the codebase, the focus tends to shift towards immediate restoration of functionality to meet deadlines, often at the expense of performance considerations. Tasks such as commenting out old code, introducing new implementations, and modifying queries become prevalent, overshadowing the original design patterns.

While the skill and dedication of individual programmers still plays a significant role, the chaotic environment of a maintenance project leaves little room for methodical contemplation or adherence to intricate design principles.

You may read the complete thread here.