Design Patterns in Everyday Architecture

Software Design Patterns were a sensation when this book about them was published. I became aware of this book in 2001 when a team I worked with was using design patterns. The book promoted software design patterns similar to using a cookbook in other engineering disciplines like building architecture or electronics. The authors define a Design Pattern:

A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.

It all made sense. And yet…

I have a confession to make. I haven’t used Software Design Patterns in a very long time. I think I developed an aversion to them. In the last project where we actively used them as a team, we developed a massively BDUF (Big Design Up Front) and the project was an utter failure, ultimately being canceled and many people on the team being laid off. Since then, while I am a proponent of thinking about the project up front, I also know that the team can and will get lost in oodles of documentation. Our team did and ultimately that documentation was of little value to our stakeholders.

Our team used to work like this: we would see a problem that needed to be solved and then look through the Design Patterns book for a solution.

The problem with doing that is this: often the pattern didn’t precisely solve our solution. Since we worked on embedded systems, object oriented solutions often not used to save memory. Our patterns seemed to be a lot simpler then what was presented in the book.

I found a lot of criticism of design patterns on the internet. One person felt that design patterns only existed because of language restrictions and that in languages like Perl, the patterns are built in and ready for use. (This poor guy got a ton of backlash for not believing in Design Patterns).

The biggest problem I had with design patterns is that the ones I wanted to use weren’t in the book. That said there is an effort to create a larger repository of design patterns. Since I’m working mostly with XML for my work, I plan to explore this XML repository.

My experience with Design Patterns left me running away from them. While they have some obvious detractions, it’s worth it to look at them again and see if I can find a use for them in my daily architecture work, where decisions are not usually made up front but on a daily basis.