Why hate design patterns?

Here we go again. First and foremost, I know that every one and their uncle :) is writig a response to Joel's "Duct tape programmer" post. Is it just me or from time to time Joel just spew some controversial stuff just to measure his influence on the world. Anyway I'll bite...

Now I'm not going to bite the whole thing (obviously, some people who are more capable than I am are already replying), I just want to say this: what's up with all these "design pattern haters" out there?! Joel associate design patterns with astronout architect... really now? (or maybe he's just associating design patterns meetups with astronout architect ... I can't really tell).

Here's a quote from the GOF book:

"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"

Notice the words names, motivates, explains and describes in the book. These words refer to the action of communication. And frankly, at least for me, design patterns are first and foremost a tool for communication. Sure just like everything else in this frekin' world, design patterns can and have been abused... but do you tell your junior programmer who tests every setters and getters that he should never ever write unit tests anymore while he shall live so help him God? No, you teach and coach. The same goes with design patterns, you have to (suprise suprise) teach people to use them properly.

Of course there is also the " lets us just cobbled some code together and if we see a design pattern fits somewhere, we just intergrate one in the next refactoring exercise" camp. My question is... why?

If you know that you need to traverse a collection of stuff in Java and do different things to different objects depending on its type... why not just use the visitor pattern straight away? Sure, you can kick off some cobbled together something and then decide to refactor to the visitor pattern later, but what if the programmer that did the first solution left the company and a new programmer is hired and you are stuck having to explain what has been done. SUre, that's a boatload of fun... or rather, you can just say that you use the visitor pattern... which you, the last programmer and the current programmer already understand. Now that facilitates communication and saves a whole lot of time.


In the end it is neither technology (COM, or CORBA) nor methodology (agile or design pattern or "duct taping") that is going to win the battle, but rather, its people. The more good people you have, either they are duct tape programmers or not, you will win. I think Joel knows this already. He talked about this in one of his old article. To get enough good people, you need good teachers. Now, duct tape programmer or not, if you cannot pass down your art, then you are just as useless as a used duct tape.