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 dofactory.com. 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'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (1)
February 08, 2011
Thanks bro I found your blog usefull.