How to teach Design Patterns to a team

Question

I'm a huge fan of the classic Design Patterns book. I very diligently worked to learn most patterns and how they are used (and when they should be avoided). However, I frequently encounter teams where I am the only one touting the book on a regular basis. I was hoping that learning this book would make it easier to explain concepts to other developers, but most have yet to invest the time to learn such topics.

These are major systems that need a solid architecture. I don't want to constantly say "read the book". How do I encourage the regular use of design patterns without coming across as pompous? Has anyone been successful in having an entire team learn and use design patterns?

Answer 1

I would suggest not evangilizing design patterns, instead advocate specific designs/approaches for specific problems as they are encountered.

Later when a similar situation occurs, you can harken back to the approach you took for the earlier problem. Then you can call it a "pattern" that the team has seen used to solve real problems with real benefit.

I would also not strictly adhere to the design patterns in the book for their own sake. It may blind you to good suggestions from non design-patternistas or blind you from real problems that may be specific to your environment/problem domain.

Answer 2

Code review.

Forcing them to use design patterns will likely lead to overuse and anti-patterns.

Answer 3

I confess that I've never tried to do this, so I'm drawing on general observations about how teams can improve their skills and the quality of what they produce. How do people learn? Reading, experimenting, imitating, mentoring ... even listening to lectures! I think you'll need to apply several different approaches. I'd say that two things are critical: exposure to ideas and feedback.

Hence for a team I would do the following:

1). Design and code reviews. The reviews not to be conducted only by seniour people. Have juniors also read code and comment. Ideally they learn too.

2). Design wokrshops toss problems around and come up with alternative solutions.

In both cases I'm less concerned with Design Patterns (the book) than in inculcating a spirit of evaluation and consideration for design. What's good? What's bad? What forces and compromises lead to this particular solution. When is good enough enough?