Pattern Value System

The ethics stem from a session that NormKerth ran at the first PLoP, and it ties back to ethical concerns that the early software pattern advocates held crucial to the success of patterns. I've written about them to some extent in some of the columns I've written for C++ Report, and you can find extended discussion of them in the SoftwarePatterns management briefing from SIGS (which I understand is going to be taken over by ColumbiaUniversityPress? and redistributed, hopefully at a reasonable price). Here's a summary of things pattern-writers should be concerned about. Most of them take some inspiration from Alexander's work, and it's probably a good idea for every pattern practitioner to spend a good amount of time reading at least the more accessible of Alexander's works:

Aggressive Disregard for Originality. This phrase, coined by BrianFoote, speaks to how we value experience. We don't value new ideas for their own sake. Other communities should and do value novelty, but we want patterns to be a haven for ideas that have repeatedly proven effective and useful in actual use.
We believe in giving credit where credit is due. If you are using someone else's pattern, cite it; if you are writing a pattern based on an idea you got from others, credit them.
We believe patterns are one tool in our software toolkit; they are not a panacea; they will not lead to wild jumps in productivity. They are about building competence. To hype patterns beyond these modest roles in software development is irresponsible.
We value "real stuff." Patterns are based in experience and convey real direction and structure for solving problems. They don't tell how to find solutions to problems; they _are_ solutions to problems. We'd rather write patterns than talk about writing patterns. We can learn a lot by writing and critiquing patterns, and that's our focus.
We strive for "The Quality Without a Name" (which Alexander now refers to as "Wholeness"). We care about aesthetics.
We care about the human side of software. All software serves some human need or want, and patterns should make explicit how they improve the quality of life for someone as a result of the pattern being applied. And we believe that patterns can never replace the experts whose knowledge they encode, nor the programmers who expertly interpret the knowledge to engineer, craft, and sculpt wonderful works of programming.
We believe the constraints of the pattern form are in fact liberating, as they allow us to focus on important aspects of design beyond the form.
We believe that there is high value in the work of coders, of those who touch the end-user deliverable artifacts. We believe they contribute as much or more to the design soundness, functionality, and aesthetics of a software system than those who usually are viewed as having all the insight and influence (architects, methodologists, etc.)
We believe that users should participate in the design of the systems they are using, including the software they will be using. In general, the pattern community fosters a sense of community, and strives (and sometimes struggles) to build an open community. We believe we can learn a lot from other disciplines; software is an awfully inbred community.

Are these universally held? No. Do we follow them as much as we'd like to? No. But they're fairly normative across the pattern culture. And most of them have quite a bit of thought behind them; they aren't just arbitrary. They come from a growing community of people who care.

Tasteful editing is invited.

-- JimCoplien

Interesting. I don't understand it yet. It seems to express some of the differences between patterns and other related approaches. For example, tools like wizards and code generators share the "aggressive disregard for originality", but to me they seem to devalue the coder and replace the expert. And that seems natural while this pattern ethics seems self-contradictory. Probably the resolution of that conflict lies in affirming the complexity of the real world. Automate what can be automated, but accept that you cannot automate everything. -- DaveHarris

Yes -- I would heartily agree with that. Some things can be automated -- by all means automate them. Some things that were patterns to me as an assembly language programmer and compiler writer of 25 years ago are now automatable, so today's patterns may be tomorrow's automatable stuff.

I think you have this just right -- so many people have trouble seeing that this balance can exist... Are you sure you don't understand it? :-)

-- JimCoplien

I'm not sure "automating" things is what I'm about when I'm working with patterns. I view it as something more like templates -- where a "pattern" is something more like the thing a dressmaker or cabinetmaker uses.

While I don't find "simple" patterns, like mail merge programs, emacs macros, and c #defines, very interesting, something profound happens when the pattern and its application can be interchangeable.

As DouglasHofstadter says in LTbdM:

But now imagine a repertoire of more and more templates, ever more complex -- thousands, perhaps millions. Imagine further that when a template's blanks are filled, other templates can be used as fillers, thus producing nested structures, and this can go on for any number of levels, thus allowing blanks to be filled in by whole phrases, themselves possibly having further filled blanks inside them -- and so on. Imagine the steadily increasing subtlety of the data used to guide the selection fo the most suitable template out of a vast set of potential templates store in memory, and to guide the filling-in of the chosen template's slots. Imagine putting sentences together from more and more small units, making less and less use of long, purely canned, rigid phrases. At some point, the performance is going to become surprisingly and impressively fluid-seeming.

Substitute "pattern" for "template", and you begin (I hope...) to see my personal view of what "this pattern stuff" is all about.

-- TomStambaugh

Ive sort of coined my own pet-phrase for what Cope says in the third bullet above (To hype patterns beyond these modest roles ...). I mentioned it during an email correspondence with DougLea. Doug singled out the phrase, saying he "loved it!" and thought it was worth mentioning somewhere more public (so I thought I'd record it here ;-)

I call it The Hype-No-Cratic Oath: First, do no hype!

--BradAppleton