More Pattern Definition Thread

continued from PatternDefinitionThread

Two little bits of homespun philosophy, if you can stomach just a little more this week ;-)

Generally Accepted Principles:

When most of us say "Patterns" we're saying "best practices". When I say "I'm using a moderator here", I'm really saying that I'm using the commonly accepted industry practice of keeping some abstraction above some things which shouldn't have to depend on each other directly.

Patterns are the software development equivalent of GAAP. If you don't use them, it doesn't mean your answers are wrong, after all, some bookkeepers don't use GAAP but their numbers are right, and survive IRS audits nicely. All CPAs use GAAP, and if you understand these principles, you can more easily understand and work with the books they keep.

Likewise, GAAP weren't invented by some genius IQ over a bowl of dope one day, nor was it the invention of non-accountants who wanted to impose their will on the world. It was the codifying of best practices for building auditable and maintainable accounting records. At least that's what I believe about GAAP.

If patterns is not "Generally Accepted Object Oriented Principles", then it's not being done right.

When we mine patterns, we're looking for practices which are generally accepted in the domain we're looking in. The very immaturity of our field pretty much demands we do this.

Explaining to Managers, etc:

Now, as far as needing to explain patterns to your bosses in order to be allowed to use them, isn't that maybe just a little silly? It's sort of like an architect asking a future homeowner if it's okay if he uses method X to calculate the load on certain load-bearing members.

Asking permission to use patterns to me is a lot like asking my boss for permission to use algorithms or language constructs. The use of patterns clearly does not constrain me or require more time in the schedule, nor does it change the way in which my project is managed. Well, except that we might be done sooner than if we invented every bit of it from scratch, and it might work better if we build it using other people's knowledge.

Pattern use isn't something we do. It's a way we do things. WHAT we're doing is exactly what we're told to do. If someone has a problem with a particular design, we can explain the pattern/principle behind it.

Publishing patterns is something we do, but it's easy to explain that we're just doing a "lessons learned" or "best practices" paper so that later designers/programmers know what it is we did, and why. Most bosses I've had are happy if not over-enthusiastic to have us explain the project. We tell them that the 'pattern format' is how we explain the design, and that the format is generally accepted in the community.

Explaining to Friends:

The more zen we put into it, the larger the backlash. We tell people it's "little reusable mini-designs, with instructions on whether to use them" and that's a good start. We tell them that we do it so that "we can repeat other people's successes, and they can repeat ours".

Then we listen to Master Cope and get them involved in reading and reviewing the darned things.

A note of impatience:

I don't know why this has to be like a 400 level philosophy debate or a masters thesis on formal definition. If you know what the goal is, and you see what the tools are, then you are able to play.

Heck, I can't define "architecture", "design", "object oriented", "microwave", "food", or "humor" in 25 words or less. Why should I explain patterns any deeper than this to people who aren't into it any deeper than this?

In the words of a famous ex-coworker: "It is what it is; now just code the damn thing". ;-)

-- TimOttinger

Eugene sez:

This is all true, but remember who the audience is for the one-liner: the CEO, the non-technical manager, the non-pattern person. The forces may be a critical element in a *designer*'s understanding of a pattern, but they are also the most abstract to non-designers. Leaving them out doesn't seem to get in the way of my non-pattern audience understanding as much as putting them in!

Hey, no sweat. I often must sell my patterns to CEOs and managers at all other levels. I do more organizational patterns than architecture patterns, and that's management business that goes beyond the realm of the designer alone.

Forces? Translate: tradeoffs. Let's understand the business tradeoffs you need to make. When an executive gets to work in the morning, what do you think they ask themselves?

What problems do I need to solve today? (yes, probably, so I key on their interest in particular management problems, like how to split a project across locations in different countries);
What context do I need to look at? (i doubt it; they're mired in context, and to get them to think about their context takes more introspection than I can make a case for in a sell job. they must eventually face their context, but it's a deeper issue than "problem").
Forces (you bet -- that's what managers spend most of their time struggling with: tradeoffs).
Solution (yes, they like magic).
Resulting context (some of the better managers can think ahead this far, others can't. if i see a far-thinking manager, i make it a point to include this aspect of a pattern)

Of these, forces have the most compelling power. Managers know of the literature that provides pat solutions to pat problems. If they like that kind of stuff, then I have nothing to interest them if I portray patterns as problem/solution pairs (even if I throw in context). If they don't like it, then the problem/solution pair approach discredits patterns in their eyes. But they don't see much literature, or many management techniques, that deal with tradeoffs.

Gotcha. Now they're at the Gate, and you can start to take them on the road to systems thinking and introspection.

Maybe this is just a special case of: know your audience. Be all things to all people. It probably means that I need to approach CEOs different than you do, and that I need to approach them differently than either of us approach designers. But I think they have no problem understanding forces.

-- JimCoplien

Should a pattern be "good"?

First, to start with (but I'll come back to this at the end), let me dismiss the moral notion of "right" and "wrong" as synonyms for "good." There's a difference. Individual patterns are not so much about morality's "right" and "wrong" as they are about "good" in the sense of classic architecture. Vitruvius defined "goodness" as a three-legged stool: utilitas (commodity, or utility), firmitas (durability, maintainability, stability), and venustas (delight).

I've been reading a lot in the anthropological literature lately about the casuistic, economic, and psychological theories of value. So let me twist the question a bit to re-interpret the quest for "good" to the quest for "value."

The pattern value system itself is based on the casuistic theory of value: that is, we believe that things are good because they've worked before. Patterns are a way to hand down culture from generation to generation, aspects of culture that would otherwise be lost, particularly because we work in a low-context culture.

Someone in a recent post said that anthropology discovers the obvious. That isn't just a metaphor for what we're doing; it's exactly what we're doing. This is about the normative practices of a culture.

Most people use patterns because they are attached to the economic theory of value: it helps them build or do something that, by comparison to something else, makes them desirous of the pattern's intended end. In short: quality, profit, and all that stuff. I think that's where the pattern discipline is stuck right now. As Alexander told us at OOPSLA, we're hired guns.

I'm encouraged to see more and more discussion of patterns that are motivated by the psychological theory of value. We do X because it feels right. In an industry where we have "formal envy" and keep seeking the numbers that will drive us in the right direction, the best designers trust their gut. They do Bridge because it feels right; the pattern encodes the experience of many that have gone before and felt good about it. You don't see a formal analysis of Bridge in GOF; they appeal to your reason. For the experienced practitioner, Bridge conjures up the good feelings that have gone with its prior application. We can rationalize many of these patterns in terms of coupling and cohesion and in terms of other measures, but it all comes down to the peace of resolution of forces.

Hmmm, "peace of resolution of forces." I like that phrase.

This is what the Quality without a Name stuff is. And to me, it's not just hooey. If you look at what's going on in the change management arena under people like JerryWeinberg and to some degree PeterSenge and that whole lot, much of it derives from the psychology of programming. You can assess whether you have a disaster or opportunity on your hands not from objective data -- that would presume more omniscience than we an ever garner -- but from emotional cues. That's why a pattern should "feel right." It ties into what change management folks are talking about at the level of organizational architecture (which is where my patterns hang out). If you think about it, it ties into how you evolve a program, too, at least if you care about the Quality of the program itself when you write it.

(Part of the problem is that too few programmers care about the quality of the program itself, but view it as a means. I don't believe you can so easily separate the too. Cruft finds ways to pop out.)

Alexander's most radical thesis is that aesthetics are objective; that is, that though you can't formalize the feelings and the drivers for them, most people will agree on fundamental beauty when they see it. (It's hard to make sense of this without suitably scoping terms like "beauty," but that's another discussion.) He provides a bridge from the objective world of analytical science to architecture, which in this century has been shrouded in mystery, magic, and the celebration of individuals with indiscernible insight into goodness. He's trying to demythify that aspect of architecture to put it at the disposal of the layperson. Part of the demythifying relates to the pattern form, and the fact that it surfaces issues of firmitas (something can only stand up and be stable if its forces are balanced) and utilitas (every pattern relates to what "happens there" in terms of human impact; all good patterns clearly contribute to the quality of life for someone, somewhere). But that's just good old architecture. Alexander restores the venustas of classic architectural tradition that was largely lost in the industrial revolution, or thereabouts. A couple of interesting things happened then: 1. the rise of modernism (a belief in the universal power of scientific method, which carried through the early 20th century), and 2. the rise in a belief that aesthetics are subjective and mystical (contrary to the position held in most of the modern era). What makes patterns different is that they're about "good guts."

And that is good; that's the underlying value system; the underlying morality. You can look for a sense of right and wrong at this level, but that's an individual quest, in my opinion. I have ideas what it means for me, but know I'd be hard pressed (and ill-advised) to try to get others to adopt the same interpretation. As someone said in an earlier posting, this QWAN thing is something we'll just have to let happen in its own right.

-- JimCoplien

CategoryPattern