Why create a list of the top 100 patterns?

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:

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:

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.