New Brief
8/13/97, 2:25:42PM by NetAttaché Light New Brief
8/13/97, 2:25:42PM by NetAttaché Light
John Vlissides is a member of the research staff at IBM's T. J. Watson Research Center in Hawthorne, NY. He can be reached at vlis@watson.ibm.com.
A long with all the hubbub these days about patterns comes more than a little confusion, consternation, and misinformation. This is partly a reflection of how new the field is to mainstream software developers (although it's not, strictly speaking, a new field). It's a fast-moving field too, which creates vacuums of facts. And yes, we pattern proponents deserve some of the blame for not educating people as thoroughly as we'd like, though not for lack of trying.[1-5]
This is my humble attempt at dispelling the more egregious misconceptions about patterns, misconceptions I've heard often enough to qualify them as patterns in their own right. (I actually toyed with using a pattern form to articulate them; then it dawned on me that reducing everything to patterns was itself a misconception!) Keep in mind that I'm not speaking for the pattern community. I expect most pattern cognoscenti would agree that these are prevalent misconceptions, but they may disagree with how I dispel them.
Mulling over what I've heard people say over the years about patterns, the misconceptions appear to fall into these categories, and so I'll organize misconceptions about what patterns are, about what they can do, and about the community that's been promoting them. Each of my "top ten" fall into one of these categories. So, I'll organize them accordingly, looking first at misconceptions about what patterns are.
This is one of Christopher Alexander's definitions, and calling it a
misconception will be heresy to some. But a simple counterexample will
make its deficiency clear:
Problem: How do I redeem my winning lottery ticket before it expires?
Context: The dog ate the ticket an hour before the deadline.
Solution: Cut the dog open, fish out the ticket, and run to the
nearest redemption station.
This is a solution to a problem in a context. It is not a pattern. What's missing? At least three things: 1) Recurrence, which makes the solution relevant in situations outside the immediate one; 2)Teaching, which gives you the understanding to tailor the solution to your variant of the problem (most of the teaching in real patterns lies in the description and resolution of forces, and/or the consequences of application); and 3) A name by which to refer to the pattern.
To be sure, a satisfactory definition has proven elusive, as witnessed by the on-going debate in the pattern-discussion mailing list.[6] Contributing to the difficulty is the fact that a pattern is both a thing and a description of similar things. One way to differentiate the two is to use the term "pattern" consistently to refer to the description of the thing, and use "pattern instance" to refer to a concrete application of a pattern.
Now, defining terms may prove a futile exercise, because a definition that's meaningful to one audience (say, programmers) might be totally meaningless to another (say, executives holding the purse strings). So I won't try to come up with the ultimate definition here. Suffice to say, any definition that stipulates a pattern's constituent parts must talk about recurrence, teaching, and naming in addition to problem, solution, and context.
I call this "the belittling dismissal." It's natural to try to reduce something unfamiliar to something known, especially if you're not motivated to investigate the unfamiliar. And all too often people put old wine in new skins and call it innovation. It's good to be wary. But the belittling dismissal does not come from experience. Often it's based on superficial familiarity, with an added dash of cynicism. Besides, nothing is ever totally new; people have had patterns in their heads for as long as there have been heads. What's new is that we've started naming the patterns and writing them down.
Now about those comparisons: There is in fact a pattern jargon—terms such as "pattern," "forces," Alexander's "quality without a name," and so forth—but patterns hardly reduce to jargon. Compared to most areas of computer science, patterns introduce relatively few new terms. That's symptomatic, actually. A good pattern is intrinsically accessible to its audience. It may well use the jargon of its target domain, but there's rarely a need for pattern-specific terminology.
Neither are patterns rules you can apply mindlessly; the teaching component should counteract any such tendency. Nor are they limited to programming tricks, even though the "idioms" branch of the discipline focuses on patterns that are programming-language specific. The term "tricks" is a tad pejorative to my ear, and it overemphasizes solution at the expense of problem, context, teaching, and naming.
No doubt you've heard of an innovation's three stages of acceptance: first it's dismissed as rubbish, then it's merely nonviable, and finally it's obvious and trivial—"What we've done all along." Patterns aren't entirely out of stage one yet.
Broad-brushing is unfair as a rule, and that goes double for pattern broad-brushing. There's a bewildering range of pattern domains, content, scope, styles, and quality—just flip through one of the Pattern Languages of Program Design books[4,5] and you'll see. Patterns are as diverse as the people who write them, perhaps even more so; authors such as Alistair Cockburn, Jim Coplien, Neil Harrison, and Ralph Johnson (to name a few) have gone beyond their initial forays to write patterns of varied styles and domains.
Having written, used, and helped others use patterns over the past five years, and having helped perpetrate at least one pattern-based tool,[7] I can state confidently that the benefit from patterns comes mostly from applying them as they are—that is, with no support of any kind.
When I speak on this topic, I usually point out four main benefits of patterns: 1) They capture expertise and make it accessible to nonexperts; 2) Their names collectively form a vocabulary that helps developers communicate better; 3) They help people understand a system more quickly when it is documented with the patterns it uses; and 4) They facilitate restructuring a system whether or not it was designed with patterns in mind.
For the longest time I thought item 1 provided the bulk of the benefit. Now I realize that item 2 is at least as important. Think about it: How many bytes of information flow between developers, either verbally or electronically, in the course of a development project? My guess is megabytes if not gigabytes. (I collected several dozen megabytes of email that circulated among the "Gang of Four" as we wrote Design Patterns.3 My guess is that our effort approximates that of a small-to-medium-sized software development project.) With so much communication going on, anything that makes it incrementally more efficient would yield substantial time savings. Patterns effectively expand people's communication bandwidth.
In short, patterns are primarily food for the brain, not fodder for a tool. There may yet be latent benefit in methodological or automated support, but I'm convinced it'll be icing on the cake, not the cake itself or even a layer thereof.
The misconceptions I've looked at so far deal with what patterns are. Now for a few misconceptions about what patterns can do. These come in two flavors: the overstating kind and the understating kind.
This one's easy, because patterns don't guarantee anything. They don't even make benefit likely. Patterns do nothing to remove the human from the creative process. They merely bring hope of empowerment to a possibly inexperienced, perhaps merely uninitiated, but otherwise capable and creative person.
People speak of good patterns producing an "Aha!" response. That can only occur if the pattern strikes a chord in the reader's mind. If it doesn't, then the pattern is like the proverbial tree that falls in the forest with no one around to hear it—did it actually fall? So it is with patterns: What good is a pattern, no matter how well written, if it doesn't produce a resonance in the human mind?
Patterns are just another weapon in the developer's arsenal. To ascribe much more to them is counterproductive. Underpromise and overdeliver—that's the best defense against hype and backlash.
This misconception is like unto the last one, except that it's less aggressive in its overstatement.
The generative aspect of patterns gets discussed periodically in the pattern forums. As I understand it, generativity refers to a pattern's ability to create "emergent behavior." That's a fancy way of saying the pattern helps the reader solve problems that the pattern doesn't address explicitly. Some of what I've read suggests that true generativity makes this happen almost in spite of one's self.
To me, the key to generativity is in the parts of a pattern dedicated to teaching—the forces and their resolution, for example, or the discussion of consequences. These insights are particularly useful as you define and refine an architecture. But believing that patterns themselves can generate architectures or anything else is definitely over the top. Patterns don't generate anything—people do, and they do so only if both they and the patterns they use are up to speed.
At the other end of the spectrum are unduly limiting misconceptions like this one. Frankly, I'm surprised anyone would think it. But enough people have asked me about it to propel it into my top ten. If it appears overly naive to you, skip to the next misconception.
Patterns are nothing if they don't capture expertise. The nature of that expertise is left open to the pattern writer. There's expertise worth capturing in object-oriented software design, certainly, but there's just as much to be had in nonobject-oriented design—and not just design but analysis, maintenance, testing, documentation, organizational structure—on and on. Patterns in these varied areas are now emerging: There are already at least two books on analysis patterns,[8,9] and each PLoP conference attracts new kinds of patterns. (A particularly interesting submission to the 1996 conference concerned patterns for music composition!)
Like most misconceptions, there's a grain of truth in this one. When you look at the pattern forms people use, you see variations on two basic styles: the highly structured GOF (Gang of Four) style used in Design Patterns, and the near-belletristic style of Christopher Alexander—narrative, with minimal structure. Having dabbled in pattern writing for something other than object-oriented design, I now recognize how biased the GOF style is toward its domain. It just plain doesn't work for other areas of expertise I've tried: What should the Structure diagram look like for a C++ idiom? The implementation tradeoffs in a pattern for music composition? The Collaborations in a pattern for good expository writing?
Clearly, one pattern format does not fit all. What does fit all is the general concept of the pattern as a vehicle for capturing and conveying expertise, whatever the field.
This one held water in the past, but not anymore. People are reporting benefits from patterns in journals such as Software—-Practice and Experience [10] and conferences such as OOPSLA[11,12] and ICSE.[13] Doug Schmidt has articulated several benefits in the context of teaching computer science to undergraduates and graduates.[14] While most of this evidence is qualitative, I know of at least one group that is conducting controlled experiments in an attempt at more quantitative results.[15]
As time goes on we'll get a better handle on the benefits (and pitfalls) of pattern usage. The initial returns are promising; we need more experience to fully assess the impact. It would be foolish indeed to reject patterns out of hand just because their performance remains to been measured.
So much for fallacies about what patterns can do. The last two misconceptions concern not patterns per se but the community that has championed them.
I'd love to know how these notions get started, because if there's a noteworthy aspect of the pattern community, it is its diversity. This is easily gauged from the attendees of PLoP and EuroPLoP—people from all over the world, from large corporations and small startups; analysts, designers, and implementers; students and professors; big-name authors and fledglings. I was surprised to learn that more than one regular attendee isn't even a computer scientist! The community is still in flux. Each year yields a bigger crowd and a slightly different mix of backgrounds.
Given the pattern community's penchant for publishing, one might wonder at the relative paucity of academics. The fact is that the majority of people who attend PLoP are practitioners. It appears to have always been so. Not one of the prominent early proponents of software patterns—including Kent Beck, Ward Cunningham, and Peter Coad—comes from an academic background. Only one of the Gang of Four (Ralph) is from academia, and he's the most applied academic I know. The grassroots nature of the pattern community is clearly at odds with any insinuation of homogeneity and elitism.
More than once I've heard the charge that patterns' primary use is as a source of revenue for those who write books about them. It has even been suggested that the patterns "movement" has a nefarious agenda.
Poppycock!
Speaking as one of the Gang of Four, I can affirm that we were as surprised as anyone by the reaction to Design Patterns. Certainly none of us was ready for the feeding frenzy at its OOPSLA '94 debut—even the publisher was caught off guard by the demand! Throughout the project our overriding concern was to create the highest-quality book we could. We were too busy just trying to understand this stuff to be distracted by sales issues.
That was then. Now that "pattern" has achieved buzzword status, it's inevitable that some will leverage the term for less than altruistic purposes. But if you read the works of leading pattern authors carefully, you'll sense a common and overarching desire: to take hard-earned expertise, best practices, even competitive advantage—the fruits of years of hands-on experience—and not just disclose it but impart it to all comers.
It is this passion for improving the reader's lot that motivates a sincere
and effective pattern author. Anything less is self-defeating—and the ultimate
misconception about patterns.
References
1. Buschmann, F., et al., Pattern-Oriented Software Architecture: A
System of Patterns, Wiley, Chichester, England, 1996.
2. Coplien, J., Software Patterns, SIGS Publications, New York, NY, 1996.
3. Gamma, E., et al., Design Patterns: Elements of Reusable Object-Oriented
Software, Addison-Wesley, Reading, MA, 1995.
4. Coplien, Schmidt, eds., Pattern Languages of Program Design, Addison-Wesley,
Reading, MA, 1995.
5. Vlissides, Coplien, Kerth, Eds., Pattern Languages of Program Design
2, Addison-Wesley, Reading, MA, 1996.
6. patterns-discussion@cs.uiuc.edu.
7. Budinsky, F., et al., "Automatic Code Generation from Design Patterns,"
IBM Systems Journal, 35(2), 1996, pp. 151-171.
8. Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley,
Reading, MA, 1997.
9. Hay, D., Data Model Patterns: Conventions of Thought, Dorset House,
New York, NY, 1996.
10. Kotula, J., "Discovering Patterns: An Industry Report," Software—Practice
& Experience, 26 (11), November 1996, pp. 1261-1276.
11. Hueni, H., et al., "A Framework for Network Protocol Software,"
OOPSLA '95 Conference Proceedings, published as ACM SIGPLAN Notices,
30(10), October 1995, pp. 358-369.
12. Schmid, H., "Creating the Architecture of a Manufacturing Framework
by Design Patterns," OOPSLA '95 Conference Proceedings, published
as ACM SIGPLAN Notices, 30(10), October 1995, pp. 370-384.
13. Beck, K., et al., "Industrial Experience with Design Patterns,"
Proceedings of the 18th International Conference on Software Engineering,
Berlin, Germany, March 1996, pp. 103-114.
14. patterns-discussion@cs.uiuc.edu, December 12, 1996.
15. Tichy, W., personal communication, October 24, 1996.
Acknowledgements
Jim Coplien helped me spiff up this article in remarkably short
order, and Ralph tracked down references while I was incommunicado.
—Thanks, guys!
©1997 SIGS Publications, Inc. New York, NY, USA. All Rights Reserved.