Some comments about Jeff Atwood’s thoughts on design patterns

I’ve just come across Jeff Atwood’s post about design patterns. A little bit dated, and I hope he has changed his mind since then, because what he said in the post is ridiculous.

Basically, he criticized the Head First Design Patterns book because only at the end of the book did its authors advise beginners to be cautious when approaching design patterns (see full-quote of the advice in footnotes). Atwood said “…filling 593 pages with rah-rah pattern talk, and then tacking this critical guidance on at the end of the book is downright irresponsible…”, “…beginning developers never met a pattern or an object they didn’t like. Encouraging them to experiment with patterns is like throwing gasoline on a fire…” and “…patterns, like all forms of complexity, should be avoided until they are absolutely necessary. That’s the first thing beginners need to learn. Not the last thing…”. I do not agree with Atwood’s opinions in several ways

• First, his criticism for the book is totally unfair. What are the differences the HFDP authors could have made if including the advise in the first few pages? Hardly anything, if not negative effect. The target of that particular advice is for pattern beginners (since non-beginners should already know no tool should be abused) and the advice at most help as an excuse for some to stop learning about patterns and for the others to not try out the patterns and understand more about them. On the other hand, each pattern is presented with a context, if the learner misses that context and abuse patterns, then no single advice could ever help him/her. The point is, an end-of-book advice is not as important as the pattern contexts clearly described through-out the book.
• Second, Atwood’s analogy that “…encouraging beginners to experiment with patterns is like throwing gasoline on a fire…” is completely misleading. Pattern beginners will not understand patterns without experimenting them in great details - and if we limit their experiments, never dream of having them really understanding patterns. After all, how on earth can somebody know how to do something properly before even know how to do it? And remember, we are only talking about experiments, encouraging a junior to insert a dozens of just-read patterns into the production code is different story (a horror one).
• Finally, patterns do not always go imply the addition of complexity. Many times the application of patterns will reduce the complexity of the design as well as increase its expressiveness (for pattern also serves as a common design vocabulary). You can bring patterns to the “hello world” program to make it a complex beast but you can also use patterns to turn extremely complex code with a lot of flow logics into much more elegant and simpler code (that’s why somebody even wrote Refactoring to Patterns). The one who thinks patterns always add complexity obviously misses the point of patterns altogether, since s/he may have never really applied patterns to produce simpler code.

Jeff Atwood is a good writer and thinker, but sometimes he just misses the point so significantly that I can’t help but throwing back some comments.

Footnotes:

• If Atwood thinks that HFDP’s authors are irresponsible, should he also consider the GoF irresponsible (since I don’t recall they include any similar advice anywhere in their book)?
• Full quote of the HFDP paragraph Jeff Atwood discussed about
  

  First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not “how can I apply a pattern to this problem.” Don’t feel like you aren’t a sophisticated developer if you don’t use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern.

  No one ever talks about when to remove a pattern. You’d think it was blasphemy! Nah, we’re all adults here, we can take it. So when do you remove a pattern? When your system has become complex and the flexibility you planned for isn’t needed. In other words, when a simpler solution without the pattern would be better.

  Design patterns are powerful, and it’s easy to see all kinds of ways they can be used in your current designs. Developers naturally love to create beautiful architectures that are ready to take on change from all directions.

  Resist the temptation. If you have a practical need to support change in a design today, go ahead and employ a pattern to handle that change. However, if the reason is only hypothetical, don’t add the pattern. It’s only going to add complexity to your system, and you might never need it.

May 9th, 2007 in OOAD, Read List | tags: design patterns

Share this entry: