Freigeben über

Why create a list of the top 100 patterns?

  • Artikel

I posted a blog entry about creating a list of the top 100 patterns that every developer should know, and got a veritable slew of responses.  In this post, I will try to do a better job of explaining WHY we need a top 100.

Concern 1: Is this a grammar or jargon?  

It is neither.  With all due respect, the word jargon is perjorative to my intent. 

Dictionary.com defines Jargon as:

1. the language, esp. the vocabulary, peculiar to a particular trade, profession, or group: medical jargon.
2. unintelligible or meaningless talk or writing; gibberish.
3. any talk or writing that one does not understand.
4. pidgin.
5. language that is characterized by uncommon or pretentious vocabulary and convoluted syntax and is often vague in meaning.

Of the five definitions, four are clearly negative in tone and intent.  The first definition, while valid, is not reflective of my intent when taken in context with the other four.

On the other hand, this is not grammar either.  The same source defines grammar as:

1. the study of the way the sentences of a language are constructed; morphology and syntax.
2. these features or constructions themselves: English grammar.
3. an account of these features; a set of rules accounting for these constructions: a grammar of English.

I am not talking about a set of the rules of discussion.  I am simply talking about creating a taxonomy of patterns that forms a basis for discussion between professionals.  It is, in effect, a jargon, but without the sense that it should be unintelligible, meaningless, or difficult to understand.

Concern 2: Different people need different patterns

I am amazed at the efforts of Grady Booch and his co-authors on his Handbook of Software Architecture.  There are over 2000 patterns there.  However, in the works he cites as inspiration (my favorite being Elements of Style by Strunk and White), there are far fewer concepts cataloged.  Is that because the Software profession is that much more widely used than the English language?  no. 

It is because the authors whittled down the list to a core set.  A key set.  A set of elements that everyone should know. 

My computer science degree required me to learn a great many things that I have not directly used since. Why?  Because being able to speak to someone whose job is different from mine, but related, is a key attribute of being literate.  It allows developers to be mobile, moving from sector to sector.  I started out writing retail software for the hospital market.  I jumped to firmware.  Then worked on the guts of an operating system.  The patterns were different each time.  But the ability to be literate was key.

A core set of 100 patterns goes a long way towards that literacy.  The number doesn't have to end up at 100, but it should be close.  Too many means overload for folks to learn the basics of other concerns.  Too few means that we are all literate only in our shared areas, which doesn't foster mobility of knowledge.

Concern 3: We aren't ready for that in this industry

Nonsense.  You become ready by forging a path for those folks who want to be ready.  That's step 1.  Early adopters will follow by themselves.  College campuses can be convinced.  The rest of us have to be marketed to and sold to.  We can never reach critical mass until we try.

Concern 4: do only the principles, doing the patterns is a waste of time.

The principles are well known.  That clearly isn't enough.  The practices need to be shared too.  Not everyone in the world is a budding Grady Booch.  Some coders are just coders.  They like writing code.  They think in code.  I am still a little bit like that.  It's where I came from.  I didn't mine patterns or submit papers to a PLoP conference.  I would not have known how, but I have benefited from the patterns movement and literature. 

Robert Martin shared a great set of principles over a decade ago.  They are still linked on his site. 

Conclusion: we need the top 100 patterns.

Using a top 100, we force the conversation.  What are the elements we should all know about EACH OTHER'S work? What are the key learnings that we should be able to share and discuss?  What elements, if shared, have the greatest potential for impacting other areas?  What principles, when expressed in code, change the mind and the thinking in the most elemental way?

The rest is gravy.

Comments

  • Anonymous
    February 14, 2007
    The comment has been removed

  • Anonymous
    February 15, 2007
    The point I was making in the comments to your previous post was not that learning design patterns "...is a waste of time", rather that it is more important to have a deep understanding of the motivation for creating a pattern in the first instance. Knowing the principle makes it easier to spot where a pattern might be appropriate AND also the tradeoffs in using it: Flexability often decreases Understandability. I do not believe that getting programmers to rote learn 100 design patterns will in any way improve the quality of the software they produce. As Grady Booch and I pointed out, the most common patterns are going to vary in different domains. "A pattern is a (recurring) solution to a problem in a context" Some average developers struggle with naming things correctly, let alone the simple application of a pattern.

  • Anonymous
    February 15, 2007
    The comment has been removed

  • Anonymous
    February 16, 2007
    The comment has been removed

  • Anonymous
    February 18, 2007
    I think you make a good case, Nick. I certainly don't believe that underlying principles are exclusively important, and agree that a grammar and taxonomy are necessary to ensure cooperative effort via communication of architectural ideas. In my case, my only agenda is cautionary. Once a grammar is established, it is often the case that many practitioners will embrace the grammar and ignore the principles, which is a fatal mistake. In other words, I am emphasizing that balance must be emphasized. The reason that there are so many patterns is that the patterns themselves arise out of requirements, which constantly change as the technology evolves. All of these patterns are based upon underlying principles, applied to an increasing variety of combinations of requirements. So, the danger in emphasizing patterns is that of losing the ability to create new ones in answer to new conditions. Again, note that I agree with your premise that a common grammar is important, and that a comprehensive familiarity with existing common patterns is important, and worth pursuing. As in any other science, we all have our specific areas of interest, and your interest in grammar is natural, due to the sheer size and complexity of the enterprise and projects you work with, and the necessity of coordinating large groups of people and organizations. Like programming languages, the language of architecture must evolve and grow to meet the evolving demands of the times. My particular emphasis arises out of my own experience, in working with small groups of people, and on my own, and my fascination with mathematics as the underlying principle that governs everything. I don't think that mathematics has been applied widely enough to many disciplines. When it is applied, it reveals much, such as when Isaac Newton began to apply mathematics to understanding physical behavior. However, mathematics, and understanding the basic underlying principles of a thing are not the only things necessary to work successfully in any field. Language is an abstraction that arises out of a need to communicate concisely about real-world problems. Without common language, communication is ineffective. I believe you are in an uncommon position to facilitate the discussion of that aspect of software architecture. I only hope to contribute to your efforts, by providing some "footnotes."