Maintenance projects and DPs

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?

..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 agree with the author, I still am skeptical about the application of Design Patterns for such a project. Many, if not most, of these maintenance projects do not either have any documentation at all or have insufficient documentation on the background or architecture of the application. How do you just get to know the patterns used just by looking at the 2-3000 odd files in the project folder? The Application designers may have followed a pattern to begin with, but when the same code passes through a dozen hands (maintenance projects usually see a lot of resource rotation problem) the pattern thing takes a back seat. You simply comment out old code, tuck-in yours, alter and add few queries, all this forgetting about the performance issues, the focus is simply on restoring and ensuring the expected functionality to meet the deadline. I agree a lot depends on the programmer himself but then it?s difficult to meditate sitting in the market-place.