Value Of Patterns

Aside from any DefinitionOfPattern, could we ask what is the ValueOfPatterns? How do they contribute and what do they contribute? Is that they express Truth, or how / why are they Useful? etc. Include, if you will, the value of a PatternLanguage as well as a solitary pattern or group of patterns.

AlistairCockburn: I think it is really just the name that is valuable.

RichardDrake: I give Alistair's reason 9 out of 10 (but I'm open to lobbying).

PhilGoodwin: Well, the name has to be attached to something though doesn't it? I think that the something is valuable. KentBeck recently related his use of a Money pattern on the XpMailingList. Every reification of the pattern yielded something different. A union of all of the Money classes he's ever written would not be a useful software artifact. But the pattern for Money is useful and I have a list of reasons for that: it has a name that can be used as a shorthand for the whole pattern (which is what I think Alistair was referring to), it describes common problems in implementing representations of Money, it expresses what has been found to be the commonalities and variabilities among implementations of Money representations, it addresses a common problem and it is flexible enough to be of some use in all instances of the problem.

The most I've got out of software patterns (be it GoF/Fowler/PLoP) is that they have led me to the thoughts of ChristopherAlexander and by this shown that it is all right to think about software in these humanistic terms. I see (software) patterns as a way to reaffirm that when we build software we are humans engaged in a human activity for the benefit of other humans. -- KeithBraithwaite

BillBarnett: I see several ways that patterns bring value to project teams, but they seem so basic that I'm worried I'm missing the point of the question. Primarily it is that they put "flesh" on otherwise abstract ideas. They give us a common language, verbal shortcuts, really, that accelerate our ability to leverage previous experience. This common language applies across company and development project boundaries, so that the ideas can spread more quickly. They help us communicate "truths" about design, process, or organizations. They almost seem to let us share these truths in the form of stories - at their best, they are close to being proverbs or parables.

LarryPrice: I tend to think that patterns describe abstract structure, you can't say that situation a is the same as situation b but you can point to a similar constellation of relationships.

When studying perception and knowledge, you find that patterns are fundamental. There is no spoon... only a particular perceptual pattern with which you have associated the notion of 'spoon'. Patterns discovered in the spatial dimension constitute various sorts of physical objects. Patterns discovered in the temporal patterns constitute various sorts of verbs. Words, themselves, reference patterns and are used to communicate them... you may truthfully state that a 'dog' exists when you recognize a certain composite of features and traits... and by communicating that a 'dog' exists, you communicate that this pattern has been identified. Numbers, shapes, and colors are all patterns that exist within the observer. Either the natural state of a pattern is 'reified' or nothing we observe should be 'reified' because there is no inherent or provable distinction between identified patterns and identified objects. Patterns only ever exist within the observer for there is an infinite, entirely arbitrary set of paradigms... there is no inherent reason to separate the dirty sock, the middle level of the bookshelf, and the muffler attached to that Hyundai as three 'separate' patterns; such reason can exist only within an observer. For us, the reason to recognize one pattern and not others is based in its utility in predictions... thus, for spatial-patterns, we tend to identify amalgamations of sensory data as being 'physical objects' when the perceptual pattern moves or reacts in certain manners... e.g. move one part of the spoon, and the rest moves. It is a basic yet valuable prediction. We identify as 'dancing' the rhythmic motion of the body to 'music'. Every single pattern that we recognize, we recognize because it proves useful in predictions. This holds just as true for DesignPatterns as it does for nouns and verbs. 'Good' DesignPatterns are those we learn to recognize as leading towards success or flexibility, whilst 'Bad' DesignPatterns (or AntiPatterns) are those we learn to recognize as leading towards failure or fragility. They are not, inherently, any less 'real' than my spoon; they just aren't physical.

GeoffSobering: Well, my SmugLispWeenie friends claim that patterns are just OO workarounds for useful features that LISP has intrinsically (ex. map() vs. Visitor).

I try to be a bit less dogmatic than that, but I've come to believe that what people often mean when they talk about patterns are a range of "things" from the very specific structural constructs (ex. ObserverPattern, VisitorPattern, etc.) to very broad conceptual notions (ex. SystemOfNames). They are, for lack of a better word, "patterns" - that is to say meta-structures discernible in the structure of a piece of work. In that context, patterns as a "thing" are valuable as a way to help us 1) recognize and 2) communicate (i.e. "give a name to") these higher-level observables. With a name, we can talk about them and come to conclusions about whether a particular pattern is good, bad, or "just a thing".