Everybody has hopefully heard about software patterns as applied to software development. The "Gang of Four" are legendary in software circles. This is all fine and dandy when you are constructing new code. But do software patterns apply when you are fixing bugs in software maintenance mode?
I recall a time when we released some software into production too early. The result was a lot of trouble ticket, and a lot of trouble. It got to the point where we had to call an emergency meeting with the entire project to brainstorm ways to turn around the problems. One of the programmers stated that he read the famous software patterns book. And he wanted to apply some of that logic to our problem. He was politely but immediately turned down.
The idea of software patterns applied to bugs may not be a bad one. It all depends on your outlook on software maintenance in general. Is the goal to hack together a solution as quickly as possible to resolve the problem? Or is the goal to come up with the solution that best improves the system as well as resolve the bug? This second option will most likely take the most time locally. But it may provide the best overall return on investment. The problem is that this is a hard sell when users need a fix yesterday.
To apply software patterns to the bug arena, it might be best to refactor the problem resolution phase as follows. Determine what the actual problem is. Then with that insight, determine whether there is a way to redesign the broken part of the system using the simplest pattern to improve the code. This does not need to be done for the sake of using patterns. But it should be the first consideration in order to continually be improving the code base while performing the chore of correctly bugs. I am sure that I am not the first one to think about software patterns in this arena. However it might not be widely publicized as software maintenance is not a popular topic in the software community.
