Why following "Design Patterns" is a bad idea

When I first started work, my manager decided that it’d be a good idea to make sure I was well trained enough to design good code. That sounds fair enough. So I was given a book (or told to read a website, I can’t remember) about design patterns. The “Gang of Four” was mentioned, which appears to be a popular book that concentrates on object-orientated languages.

I’ve been told to learn design patterns at least three times now, once at university, once at my summer job, and once here at Red Gate. Maybe they’re some kind of background knowledge you need to be a really good programmer or something?

If you’re not familiar with the majoy GoF design patterns already, I would encourage you to read about them. You’ll probably like a lot of what they say and one day you might make a better design decision because of it.

But, don’t get tempted to actually use any of them.

There are some fairly obvious reasons that you shouldn’t try to apply a particular pattern all over the place in your code. Code which follows a pattern tends to spend more time talking and thinking about the pattern that it does about getting the job done. The only really valuable resource when programming is space for concepts inside the programmer’s head. For this reason, whatever you do, don’t use terminology from the pattern in your source. Make up new words. In the real world, all code is pretty much unique, and it’s important to remind yourself that.

Another reason not to follow a pattern is to keep you as good a programmer as you are now. It’s already too easy to get comfortable with an approach, and become unwilling to try another technique, without deliberately making all your code act the same. We need practice architecting, so when the next genuinely hard task comes along, or we move to another language, we have a hope.

In source code written by a variety of people, you can usually tell by the style which developer wrote it. A lot of that is the visual layout, but I also get a feeling of the mind behind the code (spanning from the feeling of peace and beauty I get from the view at the top of a mountain, to the wild fun of the mosh pit of a good rock band). That goes to show that no-one’s capable of designing code “right” (least of all a bunch of guys who wrote a book 15 years ago). So I try to be the developer that can’t be identified from their code, as I change the designs I use depending on what I think’s best at the time.

I also specifically think some GoF design patters are actively bad. I’ll tell you which at some point, but it’s best to avoid them all for now just in case 🙂