Design Patterns are Good

I’m suspicious of a software developer who rejects design patterns.

I’m sympathetic and sad if someone’s only experience with design patterns has been ugly. Yes, I have experienced code bases that were nasty over-engineered messes and that were claimed to be design pattern based. I don’t take that as reason to reject design patterns. The best and brightest ideas can be poorly implemented.

Design patterns shouldn’t be treated as ready-to-wear solutions. The Gang of Four book is not a cook book. And you don’t get points for using every possible pattern in one project.

The greatest value of patterns may be as abstract constructs for thinking and communicating about a software design. Patterns are a shorthand for expressing complex designs.

Link: How to Use Design Patterns.

There seems to be an anti-pattern meme that ranges from “I don’t want to try that” (like my six year old who won’t eat vegetables) to a virulent “I don’t need ivory tower astro-architecture.” An anti-intellectual attitude towards design patterns is a problem because software design is an intellectual activity. Further good software design can’t be simply handed down from the architect, it is the responsibility of the whole development team.

Sometimes people get set in their ways. “I’ve been doing this in this way for as long as I’ve been doing this. Why should I change now?” Well, because one of the constants in software development is constant change. It’s a young discipline. A good software developer is always developing and honing his or her skills. (Actually to be good at anything requires constantly developing and advancing your skills.)

When a software developer rejects design patterns, which are really just about communicating common ideas, it gives me pause. Is this person misinformed or scarred by a bad experience? Or has this person given up on learning new ideas?