Ben Northrop

Decisions and software development

Why Code Quality Tools Work

January 17th 2007

A year or so back, I started an informal Design Patterns discussion group while on a project at MSA. I was in a team of about 50 Java developers, and there were a few other dilletantes like me who knew Design Patterns enough to throw out the buzz words, but didn't really know Design Patterns. I figured there's safety in numbers, so we slogged through together.

Design Patterns is a great choice for a technical reading group. First, they're non-cumulative, so if someone misses the first 10 meetings, they can still jump in at 11 and contribute. They're also extremely practical. A developer can't go a week without seeing an instance of a good 'ole Singleton or Factory or Command. And lastly, there are plenty of references, so even the stingy can get their hands on something to read.


Tending to the community aspect of the group was as important as the patterns themselves. Cultivating Communities of Practice has some good suggestions for keeping the group "alive", engaged, and responsive. Robert Putnam also talks about the benefits of communities in Bowling Alone and Better Together (two excellent books). In my experience, I saw that just through some bi-weekly meetings about patterns, strong connections would form between people that otherwise wouldn't be talking. Through these connections other non-pattern information flowed - and not just about last week's Steeler game, but good practical project related stuff. Community is vital for any development project, and these reading groups were great for supporting this.

Discussion Format

Joshua Kerievsky lays out a nice format of a design patterns study group in A learning Guide to Design Patterns. Within the discussions, someone plays the role of facillitor, essentially the gadfly that peppers the group with questions, keeping the socratic dialogue alive. It was not a presentation, and this was important. We were all equals in our knowledge, so a simple conversation style let us share information efficiently and stay engaged.

Another important element was the cadence or rhythm works of the group. Every Wednesday at lunch we'd meet - and there were no problems with expectations or coordination. If you couldn't make it, you came to the next one. No problem.

Also important was preparation. Here are some questions that I created to guide the discussion:

Abstract Factory
Chain of Responsibility


Of course the best resource is the timeless Design Patterns book, by the Gang of Four. A couple other books take on the GoF patterns as well: Patterns in Java, Patterns in Java: A Tutorial, and Head First Design Patterns (poster). A number of web sites are just as helpful, like the C2 Wiki and Lastly, you can't dig into patterns without reading a conversation with Erich Gamma, Three Sources of a Solid Object-Oriented Design, or The Show Trial of the Gang of Four.

Well, this was our group at least, and I hope some of it helps with your own. Good luck!

I am currently living in Pittsburgh, PA, working as a Senior Technical Consultant for Summa, and studying as a part-time graduate student in Philosophy at Carnegie Mellon University.

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?

Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (1)

February 08, 2011
Thanks bro I found your blog usefull.