25 August 2005
James Bach recently blogged about something I've been saying in conversations with friends and conference attendees: there ain't no such thing as a "best practice".
He lays out his points in a letter to his blog readers, and I want to comment on a few of them.
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. The patterns guys had it down: A Pattern, or let's call it practice, so that we can talk more about concrete things, is a Solution to a Problem within a given Context that yields certain Consequences. You cannot avoid this basic relationship. (The patterns guys then wanted to take practices, examine them across domains, and find the commonality and elevate it so that we could apply them in a domain-independent manner; hence the reasoning behind the Rule of Three, which so many pattern "writers" seem to miss.) It makes sense, even on an intuitive level: I walk into a doctor's office, and say, "I have a cough". What's the Best Practice here? Meds? Diet and exercise? Immediate surgery? It clearly depends on the context--other symptoms, the pervasiveness of the cough, the reasons behind the cough, and so on. Doctors who fail to establish the Context before offering a Solution are often called Quacks... or sued for malpractice.
He goes on to say, "Although some things that don't exist can be useful as rhetorical signposts, "best practice" is not one of them. There is nothing honorable you get from pretending that a practice is best that you can't also get from suggesting that a practice may be good in a specified context, and making a case for that. Sure, there are dishonorable things you can get from "best practice" rhetoric-- say, causing a dull-witted client to give you money. If that has tempted you in the past, I urge you to reform." Unfortunately, the temptation is too strong, particularly for those who are pushing a new platform upon the world. Java got tremendous success from pushing patterns rather than canned solutions (and I think we pushed too many patterns, not enough practices, to be honest), and so now it seems a requirement for any new platform that in addition to the platform, you need to have an established set of practices with it to help guide the newbies to the platform. After all, how comforting does it sound when somebody seeking to sell you on a new platform, when asked "So how do I use this thing best?" turns to you and says, "We really don't know yet since there's not a critical mass of people using it yet"?
"It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists. Best practice blather becomes a substitute for the more difficult, less glamorous, but ultimately more powerful idea of learning how to do your job. By "learning" I mean practicing the skills of identifying and solving patterns of problems we encounter as testers. Of course, that will involve patterns of behavior that we call "practices". I'm not against the idea of practices, I'm against pretense. Only through pretense can a practice that is interesting in a particular context becomes a "best practice" to which we all must bow down." Again, I'm fond of the patterns terminology here, because it clearly highlights the problem he's stating here: if we think we have a "Best Practice" to a particular problem, in other words, making it a two-part tuple, it becomes a deceptively simple list: we only need state all the Problems, and the Solutions will be apparent, since when would you choose not to use a "Best Practice"? When you list it out as a four-part tuple: Problem, Context, Solution and Consequences, it becomes more clear that a particular Problem doesn't have one "Best Practice", but depends entirely on Context and desired Consequences.
I would challenge anyone to name a "best practice" for which there is no situation which makes the "best practice" a "worst practice". To use James' example:
"A doctor who prescribes a drug without examining the patient is committing malpractice. Isn't that obvious? Would you respect such a doctor? Why should we respect people who prescribe practices without regard for the problems faced in a project? The answer comes back, "What if the doctor tells you to eat right and exercise?"
Easy--if the patient is in imminent danger of a heart attack, eating right and exercise is not going to prevent the heart attack; worse yet, the exercise could even trigger the attack. Such a doctor could easily be hoisted up on malpractice charges. My father suffered a massive coronary a few years back, and the doctor warned him very clearly that strenuous exercise was out until he'd recovered to a sufficient degree that his heart could take the strain. He's fine now--by that I mean no side effects, aside from 90-something percent scarring across his heart--but has to very carefully monitor his lifestyle. Which brings up a good point, as well: if you ignore the Context when discussing the Problem, how can you tell when the Context has changed (as they frequently do over time)?
People often cite EJB as a terrible technology. Bullsh*t. People who do that are missing the point. (Even Rod Johnson agrees with this point, or at least he did in a private conversation at The ServerSide Symposium in 2004.) The problem with EJB was that it was highly oversold: another case of "best practices" gone awry--most projects don't need EJB, despite the advice from EJB vendors. (Hmm....) EJB offers a much simpler programming model when dealing with two-phase commit programming against transactional resource managers, particularly given the context of seeking something industry-standard (for fears of new programmers having to burn all kinds of ramp-up time when they're hired). That's not really the problem space that Spring seeks to solve. (Leaving the reader to perhaps realize that maybe there's a place for both Spring and EJB in the world?)
Why the frenzy to use the term, if it has so many things wrong with it? Easy: "Best Practices" are easy to sell. Who wouldn't want to hire somebody who practices only "Best Practices"? Who would want to hire somebody who doesn't? It's an easy term for managers and HR practitioners to latch onto, and this is why most of the time you see unsophisticated speakers and tech leaders climbing all over themselves to use the term. Come on, admit it, which title sounds better and more "bang for your buck" at a conference? "J2EE Best Practices" or "Patterns of J2EE"? Most developers will pick the first, every time. And, worse yet, not realize they're being sold a bill of goods.
If you find yourself tempted to use the term, stop and examine your rationale for doing so. Are you really asking somebody what the best way to use something is, without regard to context? Or are you implicitly seeking to push your own agenda? As a speaker, I routinely get questions like, "Is it a best practice to ... ?" that are followed up by, "But what about when ....?", in essence seeking to know if I change my advice when the Context is different than what they think I'm thinking about. And usually, yes, it does. :-)
Challenge to the reader: the next time you see somebody use the term, "Best Practice", ask yourself (or them) if you can come up with a situation (a Context) where it would be a "Worst Practice" instead. If you can't, or if they can't, it's probably indicative that you--or they--don't quite "get it" yet. Or, more likely, that they've just never seen a situation where it wouldn't be applicable... which then makes me question exactly how much this particular practice has been used. Think it's a silly exercise? Almost all of the great technology books in our industry have either explicitly or implicitly brought this point to the forefront of the book, even to the point where the contradict themselves sometimes. Still not convinced? Then how about this: after you can begin to see the separation between Problem, Solution, Context, and Consequences, you may be able to stop listening to "experts" and start making up your own mind.
Context matters.
Last modified 25 August 2005