Pattern Of Babel

An AntiPattern.

As the Pattern literature grows, more and more we see the same patterns cropping up with a minor tweak here or there, or cast into a slightly different context, or just bowdlerizing old collections of algorithms and techniques. Publishing Pattern papers is an easy way for CS academics to put new wine in old bottles, and for software architects to toss off something to puff up their resumes. New kids on the block inflate trivial patterns with polysyllables and ornamentation, and old kids on the block count the worth and print-worthiness of new patterns by the number of references to their old patterns.

The result is exponentiating growth and exponentiating noise in the space of published patterns. Worse, both developers and clients begin to think of patterns, not as handy communication and conceptual tools, but as clipart. OrganicArchitecture dies and software folk with originality are faced with a stark choice: conform or quit.

Therefore: Establish, via a consensual device like a WikiStoneSociety, a ranking of Patterns. This wouldn't just be a way of relating Patterns or grouping them into one or another set of categories, but a determination of how important they seem in the grand scheme of Software. A PatternLadder, if you please. For one Pattern to rise above another on the PatternLadder, it should be more indispensable in the popular view than the other.

To make this equitable, it's probably still desirable to have a number of buckets with their own ladders. To follow PoSa, perhaps the buckets could be Idioms, Design Patterns and Architecture Patterns.

Then the pattern-space will regain its integrity; new pattern candidates will have to demonstrate their popular worth rather than relying on ornaments and references, newcomers to the pattern-space will have an obvious place to start, and real improvements on old patterns will have some chance of obtaining the attention they deserve.

-- PeterMerel after another day in the trenches.

Two notions, at least one of them serious. First, someone said that 90% of everything is BS (SturgeonsLaw). The pattern literature is trying to move in that direction, it sometimes seems.

Second, however, WRT the notion of a consensual device (I assume you mean this in the nicest way possible ;-> ), I fear that the process would water down the powerful stuff and support the pap. All too often consensus seems to work that way, seems to me.

The only thing I know to do is read it all and ignore the junk. Wish there were a better way. -- RonJeffries

To me, it seems that things like this sort themselves out over time. Knowledge in a field tends to get distilled by word of mouth and very good summarization works (bibles) like the GangOfFour book. To me, the key question is whether the rate of junk production overwhelms the rate of distillation during this period of extremely active pattern inquiry. Further, I wonder how much of this work will endure in the face of changing technology and whether it will have a good period of maturity before such changes.

I saw PatternLanguageTaxonomy the other day.

On another note, there is some evidence that some of the patterns are enduring principles. I ran across a description of an OOPSLA97 workshop the other day on non-software examples of software patterns. Turns out that there are good non-software analogs for many of the GangOfFour patterns. I forget the particulars, but they are coming out in addendum. The one thing that I do remember was that the workshop was hard pressed to find a non-software example of BridgePattern. This may support BridgePatternIsJustGoodFactoring. -- MichaelFeathers

I'm afraid I'm too bitter and twisted. I think AllPanaceasBecomePoison. The better medicine patterns are now, the worse problem they'll present after they mature.

Same fundamental belief, different feeling: I'm sure I'll always be able to make good money because nothing written or coded is ever going to replace someone who can really make computers do stuff. -- RonJeffries

But I think I can tell you some non-software bridge-patterns. How about a thesaurus? Or a legal code? Or cash? -- PeterMerel


Patterns were seen as a way to solve the lack of wizards (see: instead of needing a wizard to hold a newbie's hand, newbies would use patterns ToGrok the wizard's knowledge and experience...

Newbies can't read it all and ignore the junk, since being a newbie also means being unable to distinguish quality from junk (and since AntiPatterns may look like good solutions distinguishing them can be very hard). -- BartBlanquart

If it weren't for the PatternOfBabel, how would one recognize a GoodSolution?? -- EricRidge

It has come to my attention that my comment about "OraDiploma" may have been taken wrongly. My point, perhaps poorly expressed, is that each reader, in my opinion, needs to read voraciously (as I gather you do, Bart), and to develop his or her own notion of what makes sense. Unfortunately, there is no easier way to deal with the mass of books that are out there.

We are fortunate if we have friends and colleagues who can point us to good books and steer us away from bad ones ... but in my opinion our only real hope is to take everything in and develop our own sense of quality over time.

My sincere belief is that one can learn from any book if one seriously considers what is there. By struggling with the ideas and thinking about them, trying to really understand them, one develops one's own intuition and sense of value. We may wind up disagreeing strongly with the book ... and if we know why we disagree, we've probably learned more than if we just learned what was in it.-- RonJeffries

Therefore I feel it is better to be aware of what a book (pattern) is worth, so you can rely on the information in it, rather than finding out later that all the tricks you used are mediocre/bad solutions instead of great solutions -- as you had expected them to be.

I feel that

and but I was (and am) under the impression that patterns are suited for creating wizards only when used under a form of guidance, steering people clear of AntiPatterns (or the patterns that lead to mediocre solutions).

There is only so much experience/knowledge one can acquire in a single lifetime, and requiring everyone to verify all knowledge that is available before "filing it in" would mean that you'd need a lifetime to acquire and test knowledge before you can go ahead and apply it.

How do you test knowledge without applying it?

I feel that patterns can and should be used in the creation of wizards, if we want the next generation of wizards to know more, and be able to do more, than this generation. But we can only do so if we know the patterns to be patterns (i.e. they're not AntiPatterns or MediocrePatterns? or just ProblemSolutionPairs?) -- and if the apprentice knows so too: sHe should be able to rely on the knowledge and experience encoded in the pattern to be real end existing. The apprentice should be able ToGrok the pattern without having to go out and test it. -- BartBlanquart

I'm not as pessimistic as my esteemed colleague above, but in my many years, the materials that have come my way have rarely been perfect. There will be good pattern books and bad ones. There already are. There will be good pattern book lists and bad ones, and for all I know there already are those as well.

My advice, if I gave advice, would be to associate with good and interesting people, and to sign up for interesting and challenging projects. Pick up many books in the bookstore, buy a few. Read from them all ... finish the ones that are "working" for you ... making you think, making you want to try something new. Try the things the books suggest.

Where possible, understand what the person is telling you before you reject his ideas. There's value in most everyone's ideas, and in understanding his motivation. See for example JeffMcKennaForces. -- RonJeffries

I think the problem of which Pattern of Babel is an instance is also seen every day in our human communications. Lots of English words have synonyms and speakers quickly move among the various words. Thus the internal coding of our language processor is capable of dealing with all this ambiguity. What a system like Wiki needs to restrict the Babel, or more easily manage it, is a clean way to organize and rank patterns according to some straightforward scheme that is easily used: ex. aliases (clump patterns which are really instances of the same pattern with minor differences in a bundle), antithesis - patterns and contrasting anti-patterns, related to... part of... - this classification scheme could admit of customization and extension and is really just a method of hyper-cataloging which could be in the background and only made explicit with a brow[s?]ing mode. Just a thought... what I really like about Wiki is the non-coercive, community of searchers kind of mystic - some redundancy to accommodate various POV's is good, kind of like Perl (lots of ways to do something, lots of ways to express something) -- RaySchneider

I just visited a group of newbies that are learning patterns. Their leader is an experienced developer, and he tells them what to read and what patterns they are going to use. This is an example of the GateKeeper pattern, I think.

On the other hand, it would be nice for people to organize and rank patterns. {And post these to wiki?}

The real solution is for people to make pattern languages that tie together lots of patterns.

-- RalphJohnson

I think ExplicitPatterns? are actually more use to experts than beginners. They allow the expert to understand explicitly what they previously knew intuitively. For the beginner, following a pattern without having experienced the AhHaEffect? can easily be an IdiotProofProcess. -- BenAveling

PeterMerel, agreed - we do have a problem. The Patterns Literature is now a fine MESS. This bothers me very much. It is time to ask HowCouldWeDrasticallyImproveThePatternsLiterature? -- JoshuaKerievsky

EditText of this page (last edited November 2, 2006) or FindPage with title or text search