Design Patternitis

This was originally an email to a co-worker asking for input on a set of interview questions he'd written for a senior developer role. I thought I'd publish it here as I find myself regularly repeating the sentiment.

I think we need to be quite careful with questions like "Can you give us an example of a time when a design pattern was a good solution for a problem you faced?" since, in my experience, design patterns are more valuable as a communication tool than as a buffet of ready-made solutions (at least for a senior dev.) Developers who approach every problem with a "what design pattern can I copy out of the gang of four book" mindset tend to produce incredibly poor code (both in terms of readability and performance.) IMO good experienced developers don't actively seek out particular patterns to apply to a problem. I certainly don't find myself thinking "This sounds like a job for the decorator pattern!", rather I find myself looking back at something I've written (or perhaps while writing it) and realising that, when describing it to someone else, I can refer to it as a decorator.

While I disagree with some of what the GoF book has to say about patterns, the first few paragraphs of the introduction are somewhat relevant. They describe catalogues of patterns as something that emerge from expert designer's experience, and that documenting them can help the novice designer understand how OO can work (though interestingly they seem to assume that a novice will have non-OO experience which they'll fall back on if they're not familiar with good patterns.) To use their analogy of authors, I suspect that, while patterns in novels do indeed exist, they're emergent rather than selected up front. I'm not sure that an author sets out with the plan to follow the "tragically flawed hero" pattern, rather as they write their novel it becomes apparent that the hero fits this pattern and thus they should emphasise the characteristics that make this pattern successful (and perhaps go back and rewrite a bit.)

I guess my dislike of the question is that, to me, it feels a bit leading towards the idea of a good developer being someone who approaches every problem wondering what pattern to apply next (and probably copying the implementation straight out of the GoF book sigh), rather than someone who writes good code from which the well known patterns emerge.