Warning! Pedantry and self-indulgence ahead!
I'm a big fan of design patterns and I feel that they are an almost mandatory subject of study for all serious developers. I think I'm going to make the "You really should learn design patterns" post an annual event. However, any time I've posted on design patterns I invariably get a couple comments from readers who have had very negative experiences with design patterns -- mostly from "other" people getting patterns happy and slinging them around foolishly or unnecessarily. So before I lurch into yet another exhortation to go study design patterns, let's talk about what it means to "know" something.
Bloom's Taxonomy
Bloom's Taxonomy is a classification of the different levels of learning and understanding used by teachers to set objectives for students. I mentioned this in a conversation at work last year and got some blank looks, but I think it's a very valuable tool for judging a person's grasp of a subject. One of the things that originally sparked this post (the draft is over a year old;) was a developer I interviewed that claimed to be an absolute stud at ASP.Net. Bloom's Taxonomy lists six different levels of learning. I think our ASP.Net stud was largely basing his perceived expertise on knowing a lot of facts. Memorizing the page event lifecycle in ASP.Net is an impressive achievement, but it doesn't mean crap in the greater scheme of things if you don't understand how to use those facts.
Using ASP.Net as our context, here's how Bloom's Taxonomy breaks down:
- Knowledge - A developer knows some facts about ASP.Net. They can recall information about ASP.Net. They've memorized the event lifecycle.
- Comprehension - A developer understands ASP.Net and can describe ASP.Net in his or her own words. They understand the flow of the event lifecycle and can describe it.
- Application - A developer can actually use ASP.Net to create solutions outside of the classroom Northwind applications. A developer at this level can actually earn a salary for programming.
- Analysis - A developer can trouble shoot ASP.Net programs. He or she understands the various technical pieces of the ASP.Net architecture and understands how they all fit together.
- Synthesis - A developer can take the pieces of ASP.Net and build something totally new, like a new layout framework or their own content management system on top of ASP.Net
- Evaluation - The highest level in Bloom's Taxonomy. The developer is able to make qualitative judgements about the appropriateness or effectiveness of his or her ASP.Net solution. At this point they've discovered that ASP.Net WebForms isn't an ideal architecture for sustainable development and they're studying a myriad of Rails like MVC frameworks and pondering continuation based solutions (couldn't help myself).
I'll posit the theory right here that developers are better with any given technology as they progress up Bloom's Taxonomy. I'll go even farther, you're not good at a technology, platform, or framework until you get to levels 5 & 6 on Bloom's Taxonomy.
When I was on a central architecture team years ago our management had us do a self reported skills assessment listing our level of expertise with various technologies. Looking through the complete Excel sheet you would have thought we were a veritable pantheon of Software Development gods. The reality was much more pedestrian. I think that kind of list would be a lot more accurate if we were marking our level of expertise as "Knowledge" with Java, "Analysis" with Oracle, and "Evaluation" with VB6.
So, when I say go learn design patterns, I really mean to keep climbing up past lower level Knowledge, Comprehension, and Application into the higher levels of Bloom's Taxonomy where you're more capable of making qualitative judgements about the appropriate usage of a design pattern. Knowing the names of patterns and even how to apply the patterns isn't as helpful as knowing when a pattern is and isn't beneficial. A very important part of learning design patterns is being able to evaluate the usage of a pattern in a given situation.
Why a Study of Design Patterns is Valuable
I think a study of design patterns is a great way to boost your abilities as a developer and designer of software. Jean-Paul thought so too in Build a Solid Core. I've gone down this path before, but from conversations I've had recently, three big reasons come to mind:
- Faster communication and understanding. Last fall a senior developer at my client was describing a feature of their proprietary ORM tool. All he was describing was their implementation of the "Unit of Work" pattern, only he didn't know the term for it. Because I'm familiar with that pattern I was able to quickly understand and even apply that feature in our development. If he had been familiar with the pattern name, he could have described their framework to me much faster. Moreover, assuming my explanation isn't sufficient, or they want to read over it out of band, I can simply refer other developers to the PEAA book to read a much better explanation. With a few exceptions, I've spent most of the last 3-4 years coming from behind other developers and working on existing systems. Being a student of design patterns has helped give me categorize and understand the existing solutions that I've come across faster than I think I could if I wasn't familiar with design patterns. Unfortunately the most common pattern is the Ball of Mud, but that fact is just another reason to learn about better patterns like "Layered Application."
- It's all been done. A client developer I worked with this year told me one time that he just tried to do the right thing by applying good design principles and the result just happened to look like design patterns. At which point he paused and looked pensive for a moment. So yes, Derrick, that's kind of the point of learning patterns in the first place. Most of the design patterns out there are a culmination of years of learning by developers who came before us. It's a great shortcut in your career progression to simply borrow the lessons learned by older developers.
- Know your options. I've been putting together my DevTeach talk on Design Patterns for WinForms development that will deal with different patterns for structuring WinForms screens. It occurred to me that one of the most useful things about studying design patterns is simply learning about other design alternatives. There's no way to know this for sure, but I'll bet you that the mass majority of WinForms work is done with the Autonomous View style, mostly because developers don't even know that there are alternatives like Passive View or Presentation Model -- or why those alternatives can be preferable. Who knows, maybe learning about the different branches of the Model View Presenter tree will give developers some inspiration to do something totally new and better. If nothing else, learning about design patterns will make you challenge your own designs.
