Ferengi Programmer and the Dreyfus Model
Date: 2009-02-13 00:01:58

I've been reading http://www.codinghorror.com/blog/archives/001225.html[Jeff Atwood's post] regarding http://www.joelonsoftware.com/items/2009/01/31.html[Joel's comments on the podcast] about http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod[Uncle Bob's SOLID principles] and what struck me as I read through his dislike of having too many rules and guidelines is that there is a misunderstanding of how we should use these rules and I think at the heart of this understanding the Dreyfus Model might clear this up.

To briefly recap the different levels of the http://pragmaticstudio.com/dreyfus[Dreyfus Model] (you can read more about this in http://www.markhneedham.com/blog/2008/10/06/pragmatic-learning-and-thinking-book-review/[Pragmatic Thinking and Learning])

* Novice - Little or no experience in a skill area
* Advanced Beginner - Break way from rules and try some stuff alone. Have difficulty troubleshooting
* Competent - Develop conceptual models of problem domain & can problem solve
* Proficient - Try to understand larger conceptual framework around skill. Can reflect on performance and do better next time
* Expert - Vast range of experience to apply in just the right context

Given these levels at which any person may be at for a given set of skills, as http://blog.dhananjaynene.com/2009/02/an-experienced-programmer-doesnt-use-solid-as-a-checklist-he-internalises-it/[Dhananjay Nene points out] someone who is an expert in this area is not going to be referring to a checklist of design guidelines - they have already been past this stage and are at the stage where they can apply the ideas intuitively in the right context.

____
If you are at a stage where you still need to review your design with respect to the SOLID principles (or other appropriate design principles) - please take your time to apply the principles, learn if you are breaking them, understand the costs of doing so (I would recommend that involve a senior programmer / designer in the process) and then by all means make the best judgement. Principles distilled over time and experience should be adjusted preferably by those who understand the cost and implications of doing so, +++<strong>+++the rest should strive to reach that state first.
+++</strong>+++
____

In which case the following statement on Jeff Atwood's post makes perfect sense:

____
Like James Bach, I've found less and less use for rules in my career. Not because I'm a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules.
____

But it shouldn't be used as a stick to beat the principles because using them as a set of guidelines or rules is still very valuable for someone who is not so far up the Dreyfus Model as Jeff is for this skill.

I still think there is value in re-reading the principles even when you think you have got them ingrained in your mind and don't need to keep on referring to them to write your code. I have often found that when I end up writing code which is difficult to work with it tends to be because I've broken one of the principles without realising that I was doing so.

== Overall

To summarise I don't see a problem in following principles/rules when you are new to a skill - in fact I think this is the best way to pick up good practices otherwise you are just guessing.

In order to progress up the Dreyfus Model we need to eventually start questioning the rules and working out when we should and should not apply them.

Leaving the last word to Mr Atwood...

____
Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they're never a substute for thinking critically about your work.
____