Design patterns in design reviews - John Vlissides

Having served as a consultant to a half-dozen companies, I'm struck by the similarities in what they all try to do. Each project has its unique aspects, certainly, but they are mere variables in a recurring formula. Every project has included a user interface component communicating with some sort of computation component, usually backed by a database. Every project sought to decouple these components to one degree or another. Everyone wanted to use object technology, though not everyone understood why. And while the average experience level varied, every development team struggled with the design process: false starts, iteration, and delays were the norm. These recurrences are mostly beneficial; they let one know what to expect and how to impart the most benefit. But two recurring problems proved troublesome. The following sections describe these problems and how design patterns have helped me deal with them.

Unearthing the design and its rationale

The first of these irritants was the quasi-courtroom tactics I had to adopt to get to the truth of a design. Developers usually had trouble explaining the gist of what they had done, either because they had no means to express it or because they honestly didn't know. I was confronted with one spaghetti class diagram after another. The unstated hope was that I would come to understand the design by sheer osmosis. In reality, there was never time for that.

My only recourse was relentless interrogation. I would ask question after question until I had built up a consistent mental model of the system. Inevitably that would involve backtracking--someone would contradict what was said earlier, causing a partial collapse of my mental model. Sometimes the collapse would come only after we had gone down a series of blind alleys. The more successful attempts along these lines tended to raise more questions than they answered: Why did you design it that way? Is what seems to be gratuitous complexity really worthwhile? What are your assumptions, and why are they realistic? What happens six months from now when I need new capability X?

Which leads me to the second irritant: shallow design rationale. Often the developers simply didn't know why a design was the way it was. No one bothered writing down the reasons for each major change to the design, let alone the incremental ones. As a result, we had to reverse-engineer the design choices time and again--an uncomfortable process for all concerned.

Enter design patterns

After four years of this, things finally began to change when in early 1993 I started incorporating early drafts of material that eventually became Design Patterns [18] into my consulting engagements. Rough as that material was, it gave me something concrete to offer in the way of exemplary designs. It also focused my thinking so that I could more readily identify designs based on what the developers were trying to do. No longer did I have to assume that they had developed something entirely new for me to fathom. Instead, I considered the flexibility they were pursuing as a way to isolate a design pattern. Then I could concentrate on mapping the classes they had defined to those in the pattern. If there was some semblance of correspondence, I could feel good about their design and offer constructive criticism immediately. If I could see no correspondence, then I would introduce the pattern to them. Sometimes the flexibility they sought was ill-defined or spurious; the pattern would elude me in those cases. Thus the catalog of design patterns became a kind of sounding board, a test suite for valid design. Of course, this experience helped us refine the patterns themselves.

Sharing design patterns

For all these benefits, though, the burden of pattern application fell largely on my shoulders. The patterns weren't complete or polished enough to give to the development teams ahead of time. I trotted them out as needed, but because they were hard to share with others, they tended to stay confined to my head. Their consummate benefits didn't emerge until the team members could internalize them as well.

That couldn't happen until Design Patterns appeared on bookshelves in late 1994. For my first major engagement thereafter, I insisted that each developer read and understand the book prior to our meeting. I had no delusions about this request; I thought few would read it all, let alone understand it. But that was their responsibility, and I expected most people to have at least looked at it.

As it turned out, not only had everyone read it, but a core group (5 out of 12) had a remarkably good grasp of the patterns we discussed. There was also enthusiasm, not just for design patterns but for the developers' own design as well, because they found that they had used some design patterns unwittingly. Seeing the design patterns was a vindication of sorts--it legitimized approaches they had been unsure of.

Table 1: Sources for Summary Observations

The biggest payoff: communication

But the best part of the encounter was the high level of communication we achieved. We discussed designs not in terms of classes and objects and methods but to a great extent in terms of design pattern concepts: participants, applicability, consequences, trade-offs. Discussion remained at the design pattern level unless and until there was a controversy, at which point we might drop down to the nuts and bolts. But that was infrequent. I'm happy to report that pattern concepts dominated our discussions.

In fact, I came away from this engagement feeling a satisfaction I hadn't felt after any other, and I attribute it unreservedly to the use of design patterns by all concerned, not just myself. Another engagement along these lines has been scheduled for this fall. The project under review will be a different one, with another, somewhat larger development team at its helm. As a further twist, several of the team members from the earlier engagement will participate. They will act as I did, but to small subgroups of the overall team. That will help spread the burden and hopefully permit even more incisive discussions.