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.|
|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.
5 thoughts on “Why create a list of the top 100 patterns?”
It has been 10 years since the seminal publication of the Gang-of-Four Design Patterns book. Since then,
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.
Sorry if I misdirected your quote. I was going on gut. I didn’t intend to attribute the notion to you, personally, that patterns were, in themselves, a waste of time. However, you do make the case that the rote learning of a set of patterns will not affect quality. Is quality the intent?
When we force chemists to learn the names of organic compounds, are we affecting the quality of their work? When we force nursing students to learn the latin names for the muscles, are we trying to improve the quality of their nursing? In both cases, the answer is ‘slightly at best.’
The goal is to communicate.
As I said, the most common patterns in the most common domains are worth learning, so that you can speak to people who work in those domains, and so that you can learn from them.
One more note: If an average developer doesn’t know the names of something, perhaps they should find a different line of work.
The mantle of software leadership should go to the people who are willing to work the hardest to become literate in their field. If those people happen to speak Mandarin or Hindi, so be it. Competition is good for us all.
I, on the other hand, am willing to work. I’d like to find the folks willing to learn and help guide them. Join me.
"Is quality the intent?" The overall intent is to write great software that does what the customer (really) wants. Quoting from Head First OO A & D, the steps to great software are (and I firmly believe these):
1) Make sure your software does what the customer wants
2) Apply basic OO principles to add flexibility
3) Strive for a maintainable, reusable design.
Now I’ve seen software that satisfies (1) but was a horrible, unmaintainable pile of crap internally (I am in no way advocating that this is acceptable). But the customer didn’t care! If the devs had applied points (2) and (3) it obviously might have been a different story with respect to future enhancements.
So quality relates to longevity, and the longevity is simililarly related to how well software satisfies users. So yes, quality is desirable.
When scientists learn deep principles, it frees their mind to look at the bigger picture without constantly having to remember reams of formulas. Rote learning anything will not necessarily enable you to extract the underlying principle and re-apply it in a different situation, and maybe come up with something new.
"The goal is to communicate." I think the goal (aside from writing great software) is to communciate good ideas well. Just communicating is not sufficient.
"If an average developer doesn’t know the names of something, perhaps they should find a different line of work." Possibly true! Or, we can try to instill the principles of why such a thing as accurate naming is essential. The majority of programmers start out as average!
I’m not sure what your comments on leadership and competition were related to? I was not advocating that we stagnate and simply put up with practices as they stand. Everyone who loves writing software should actively pursue new ways to do things better.
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."