Okay, that’s a bit strong, but it got your attention. In truth, I think design patterns [1] are very useful things. They can aid in understanding software design, for documenting and communicating design, and for applying to or refactoring designs; but many people see them as something more. I saw a consulting job requirement a while ago, and one of the required skills was that the candidate “must have used ALL of the design patterns [1]” documented in the GoF Book [2]
This kind of thinking entirely misses some of the primary points of the book; that the design patterns [1] given were derived from observations of recurring patterns in software, and that it’s a non-exhaustive list. Like any other tool of design, design patterns [1] can be misapplied to create bad software, and I’ve seen it happen. They can introduce unnecessary complexity, or to remove it. The ability to select an appropriate pattern in meeting a need is far more important than whether an individual has used them or not.
I can only imagine how such a requirement was decided… Some respected developer bemoans the lack of pattern knowledge to a manager, who knows the buzzwords, and maybe even reads the book. The manager in turn decides that this is an ideal, quantifiable measure of developer skill, and behold, a new job requirement is born!
Perhaps a better requirement would have been that the individual has avoided the use of any of the anti-patterns [3] documented in the AntiPatterns [4]
|
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at http://www.linkedin.com/pro/swarchitect |