These two go together surprisingly well. Apart from the fun inherent in drinking wine, these two fairly distinct areas share a common thread. Vocabulary. It’s difficult to truly taste a wine until you know some of the flavours. It’s taken a few years, but I’ve learnt what oak, truffles, cigar box, cedar, tobacco, tannins etc. mean - to me. They also tend to mean fairly similar things to other people. It’s good, because I know now what flavours I like. I can use these words to help me define a wine, and from that, communicate to others the wines that I enjoy. Design patterns are similar. A vocabulary which can be used to communicate how an area of software actually works. It’s also a way of saying what types of patterns complement each other and what don’t.

I wrote a threadpool once which used the command pattern to encapsulate the process to be threaded. That object was submitted to the singleton threadpool queue, which was protected by the double checked locking idiom. The singleton used a facade and an adapter to start up threads and execute the command before putting the threads back into a wait state. Now try explaining that to somebody who doesn’t understand the patterns involved. The beauty of patterns is that they can sum up the way a group of objects relate into only a few words. I remember when Taka code reviewed my original threadpool, he lent me The Book on patterns. I was surprised how many I had actually implemented - without even thinking about it.

The problem that I see with patterns though, is that many of the “architects” I’ve dealt with try and tell developers to “use such-and-such” a pattern. Patterns help us communicate ideas, but unlike libraries, or ActiveX controls, or whatever other pluggable compileable unit you choose to deal with, patterns just don’t cut it as plug and play building blocks. We should be highlighting that patterns help us develop by helping us communicate.

The wine maker doesn’t sit down and say, “OK, I’m going to make a wine that has strong earthy truffle notes with just a hint of oak, and some strong tannins”, and then proceed to make that. Instead, the wine maker takes the raw materials, the knowledge of the grapes, the climate history over the past however many months - adds a touch of mystique, a hint of art, and LOT of experience - and produces a wine that should be a winner. The knowledge of the flavour vocabulary, and the experience to use it, allows the wine maker to fine tune the wine, to create a structure that is beautiful on the palate, and, depending on the grapes and market, a wine that should be drunk now, or will age gracefully.

A software developer is the same. You can teach the words, and then use the words to speed up the education, but just the act of knowing patterns doesn’t make a great developer. It’s knowing how to see the patterns, identify the weaknesses, highlight the strengths, and blend the patterns together to create a fine bottle of software. The patterns, like the flavours, will emerge. And, unlike wine, we can influence these patterns by continually tuning and refactoring the software throughout its entire life.

Hmmm… maybe another glass of Pinot is in order after that.