Bloom’s Taxonomy and Design Patterns

Posted by Jeremy Miller on April 15, 2007

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:

  1. Knowledge – A developer knows some facts about ASP.Net.  They can recall information about ASP.Net.  They've memorized the event lifecycle.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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:

  1. 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."
  2. 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.
  3. 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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Design Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Pam

    This is a great blog. I am a ‘teacher’, too…and am trying to come up with a presentation to my fellow IS/IT analysts/programmers whereby they might use Bloom’s (and other taxonomies) to document their own goals and their achievements, so when merit raise/bonus time comes, they have a better chance at getting the ‘gravy’.

    I figure if academic types can use Bloom’s and other taxonomic languages to teach and evaluate students, workers should be able to use it to document achievement and goals.

    You’ve given me some alternatives, like Cockburn’s, to look at. Thanks.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    Bloom apparently wasn’t a Science Fiction fan.

  • max

    Blooms taxonomy obviously lacks the seventh level: groking.

    ;)

  • http://quiziqal.com Lee

    Very well said. I’m intrigued enough to rework the skills section of my resume with the taxonomy break-down – I don’t know if I’d ever send out this version, since I’m not sure how well received it might be, but going through the exercise seems like a great method of analyzing and reflecting on my skillset.

  • Mike

    Nearly all the design patterns I’ve looked at are overkill for what I’m trying to accomplish. I’m trying to now fix a product that was put together by a team of developers in love with design patterns, it is a mess. Overly complicated, inappropriate use, poor low level knowlege. Uggh. The first question we should ask is what is the simplist way to solve the problem we’re faced with. Not what is the coolest most advanced design pattern I can apply to this.

    I’m currently biased against design patterns. I’ve looked at them then often implemented something similar, but much simpler, more customized to my situation and lots easier to understand/maintain.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Evan,

    I know just what you mean. There’s also Alistair Cockburn’s breakdown of skill level:

    1.) Unconscious incompetence
    2.) Conscious incompetence
    3.) Conscious competence
    4.) Unconscious competence

    From Jeremy Stell-Smith: http://work.onemanswalk.com/2006/6/5/the-path-to-unconscious-competence

  • http://www.evanhoff.com/ Evan

    Great post! One thought stuck with me as I read your summary of Bloom’s Taxonomy. There’s another group of levels that go hand in hand with these (on a larger scale).

    In short, you first hit the phase where you know you know nothing (I’ve never used c# before). At some point down the road, you hit the next phase where you think you know everything (I’ve been using c# for X years and know nearly everything). Next, you hit the phase where you feel like you know nothing again (I’ve never read up on OOP, TDD, Design Patterns, Integration Patterns, BDD, RDD, DDD, and a host of other things). Next…well, I’m sure there’s another step, but I’m still in the middle of a crapload of reading. lol. ;-)

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Exactly!

  • http://dev.bennage.com Christopher Bennage

    “If I have seen far, it is because I have stood. on the shoulders of giants.”
    Sir Isaac Newton

    GoF, Fowler, Evans, et cetera.