This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: No such thing as best practices? Sure there are!
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
While I agree with their intent, I don't think I agree with what they said. Let me 'splain.
Here I'll quote Ted quoting James. (Feel free to quote me if you like!)
First, "There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice." James hits the nail on the head with this one: any practice, taken out of context, can easily be turned from "best practice" to a "worst practice" without too much difficulty.
They said "There are no best practices" and then they had to define the term... but they defined it wrong! A best practice isn't a required practice or a universally dominant practice. It's just one of the best ones. It's used quite often, but not everywhere and not always.
I do agree with what I think is their intent, although I wouldn't presume to speak for either of them. Many junior followers of any given software process tend to idolize the core practices of their process. The thought leaders, at least the good ones, in each process are saying "Experiment! Find what works! These core practices are a starting point, not a destination". But their more junior followers have found their molten idol and aren't moving one inch.
I think this comes down to a lot of what Andy and Dave have been saying about the Dreyfus Model of learning. The scale goes from one to five, with one being a rank novice and five being a wizard.
Stage One beginners ~need~ rules on a very visceral level. They can't exist without concrete rules because they don't know what they are doing. They aren't interested in learning about something, they just want to get something done. This group can't concieve of moving beyond the core practices.
In Stage Two we start to grab principals but without understanding why they are important or how to use them in context. Once a Stage Two developer finds a principal that works once, they are stuck on it! It works doggone it! Everyone should use it! It's a Best Practice! ;)
However, once we hit Stage Three, we start learning to ask questions. We start looking for reasons and understanding. We, like Spock, start to realize that logic is the beginning of wisdom, not the end of it! (Sorry for the obligatory Star Trek reference!)
Stage Four and Five do fine so we'll skip them here... their biggest problem is figuring out to communicate usefull knowledge to the Stage One and Two people.
Sadly, most people never make it to Stage Three. They find they are good enough to get by at Stage Two, so they stop searching and get productive. They know just enough to get by, or at least they think they do... but that's another topic.
Here's an example of a Best Practice abused. A few years ago I was at a user's group and ran into a guy who worked at a local XP shop. We were in a group of half a dozen people and the subject of software process came up. During the conversation it came out that everyone in my shop didn't practice Pair Programming full time. I was the technical lead of my team and said that I thought Pair Programming was a great practice to be used as needed. It wasn't something I thought should be used full time in every situation.
Oh boy! My XP enamored friend didn't like that very much! He said things like if I hadn't done Pair Programming full time for at least two years, I wasn't qualified to make that statement, and he didn't understand how we thought we could ever ship quality software without Pair Programming, and many other similar things. I tried to excuse myself and move to another group, but he followed me, apparently sure that he argued me a big longer I'd see the light. This guy stayed on my trail for half an hour, until the speaker started. He then tried to corral me after the meeting. My other friends sat back and had a good laugh at my expense while I kept moving around the room all evening!
What's the point? My confused friend thought Pair Programming was a Best Practice as defined by James. I'd say that he had settled on a Required Practice, which in my mind is different.
I realize that James and Ted are trying to make a good point, that they are attacking blind adherence to ~any~ practice. And they are right! But let's not throw a perfectly good term just because a few zealots have abused it. They'll just grab the next term we choose and hijack that one too! The term Best Practices is accepted and understood by CEOs (at least mine), teachers, experts and novices. Let's just hammer in the context part.
Previous Topic
