No Best Practices
Dear Reader,
I would like you to give up, henceforth, the idea of “best practice.” Thank you.
I want to stamp out “best practice” for several reasons:
- 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.
- 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.
- 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.
- When you say that something is a “best practice”, you may impress the uninitiated, or intimidate the inexperienced, but you just look foolish to people who believe in the possiblity of excellence. Excellence in an intellectual craft simply cannot be attained by ignorantly copying what other people say that they do. Yet, the notion of a best practice is really just an invitation to be an ignorant pawn in someone else’s game of process manners– or it’s a trick to make people pawns in your own game.
- Simple, honest alternatives are available:
- “Here’s what I would recommend for this situation.”
- “Here is a practice I find interesting.”
- “Here is my favorite practice for dealing with {x}.”
- “{Person X} attributes {practice Y} for his success. Maybe you’d like to learn about it.”
These alternatives have their own problems, but less so than than does the Oompa Loompa moralizing that lies behind “best practice.” I’m not trying to stamp out all informal communication, I’m just trying to discourage you, dear reader, from making irresponsible recommendations. Saying “best practice” is obviously irresponsible. Recommending a practice more narrowly may also be irresponsible, depending on the situation, but let’s not worry about that right now.
At this point, if you are in the habit of talking about practices that you think everyone should follow, then you must be pretty annoyed with me. You will be annoyed as well if you pin your hope for project success on finding Holy Grail practices that will endow you with grace and prosperity. You may be thinking of certain practices that you think must be best, and getting ready to throw them at me like Pokemon warriors from your collection.
And if you are one of those people who promote a “testing maturity model” then you must be apoplectic. A maturity model is basically a gang of best practices hooked on crystal meth. In my maturity model of the industry, promoting a maturity model is mere level 2 behavior. By level 3, we outgrow it.
So, first let me apologize for raining on your bubble. I have sworn to speak the truth as I see it, but I don’t enjoy this. It doesn’t make me rich, I’ll tell you that. The way to get rich in this world is mainly by making people feel large hope about a small exertion (i.e. “six-second abs”, lottery tickets, voting in an election, maturity models, and stuff like that). If you want to get rich, do not tie yourself to the truth.
Go ahead and follow your favorite practices. Just don’t preach that the rest of us must follow them, too. Keep your process standards to yourself. If you want to make a suggestion, make one that takes context into account.
Here are some common replies to my argument, and my answers:
- “I don’t mean ‘best practice’ literally. I’m just suggesting that this is a damn good practice.”If you want to say it’s a damn good practice, then it’s just empty hyperbole to call it the BEST practice, right? But the truth is that your practice, whatever it is, is not a damn good practice. The most it can ever be is a damn good practice *within a certain context*. Outside of that context it is something else. So, please define that context before you prescribe it to me.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?”
And I reply “Even that is irresponsible unless that doctor has seen me. Besides, it’s terribly vague. Ya call that best practice? It’s vacuous blah blah.”
- “When I said this practice is a ‘best practice’ I meant it was best for a certain context. But pretty much everyone in the industry shares that context, so what’s the point of talking about context?”Often when someone makes this argument to me, I like to learn something about the context they think is so universal, then talk about a particular company or industry segment that doesn’t share that context. This is not difficult.But even if, for the sake of argument, the context were universal, why call it “best”? Maybe this would make sense if there were a world championship competition for practices. If every conceivable practice were brought out and tested against every other one, in some specified context, then maybe there could be some truth to the “best practice” story. Of course, this hasn’t happened, and it can’t happen.
- “This practice represents a consensus among industry leaders.”No it doesn’t. You’re just making that up. Industry leaders aren’t able to agree on anything much of substance. I know this because I am an industry leader (based on the fact that some people have said so), and other leaders more often disagree with me instead of obeying my commands. I am influential within a certain clique. The software testing industry is made up of many such tiny cliques, each with its own terminology and values.Whenever people tell you that there’s a consensus in the industry, what they probably mean is that there’s an apparent consensus among those people in the industry whom they happen to respect. The best practice for dealing with discordant voices is: just ignore them.
(Exercise for the reader: Can you spot the sentence above where I irresponsibly declared a “best practice”? What do you think I really meant by that?)
- “Lighten up. It’s just an expression.”It’s an expression that cheapens our craft. Please stop using it so that we can build a better craft.
A valued colleague of mine recently sent me a challenge.
“Would you allow that this is a best practice — ‘Seek to understand your problems before selecting solutions for them’”
Here was my reply:
Your advice is generally good, but it is not a universal best practice.
Here’s my analysis.
- Do I know what the practice actually is?The practice you specified is pretty vague. What specifically do I do? How do I tell if I’m doing it correctly? It kind of reminds me of this advice: don’t get sick. I would like to follow that advice, but I’m not necessarily able to. I do know to avoid certain behaviors that will probably make me sick; those are the practices. “Remain healthy” or “Understand problems” are goals, not practices.
- Does the advice involve a meaningful distinction among possible behaviors?The more you try to specify something that is always best, the more you must avoid making distinctions that might run afoul of context-specific variables.For instance, here’s a potential best practice: Whatever you choose to do that is supposed to have an impact, make sure you do it in this universe, rather than in other universes that might exist in parallel with ours– otherwise what you do won’t have any impact. See? Although I am not able, in the sixty seconds in which I tried, to find an exception to this practice, the fact that there are no exceptions just makes it seem a best practice that isn’t worth discussing.
If I have no option but to follow a “practice”, it’s not really a practice, it’s just life.
So, if I want to solve a problem, do I have the option of solving it without having understood it? My answer to that, on reflection, is yes. I believe, for some kinds of problems, I can solve them without understanding them. For instance, by staying pretty much in my hotel room when I am in a strange land, I know I must be preempting lots of problems (and therefore in a sense solving them) that might otherwise befall me, even though I can hardly calculate or catalog them, and certainly can’t say that I understand each one.
I can think of other examples where there seems to be value in solving a problem that I don’t understand. Here’s one: I saw a news story about something called Dithranol, which has been used to cure psoriasis for a hundred years. Scientists recently announced that yup, it really does cure psoriasis. Up until now they weren’t sure. In other words, somebody apparently solved a problem that they didn’t understand, and that seemed to be okay.
Is it possible for me to understand a problem, solve it, and then suffer in some way because I understood the problem? I suspect that some solutions are socially acceptable only because the person doing the solving didn’t know what they were doing at the time. For instance, in California it is illegal for a direct entry midwife to help a woman go through labor, but it is not illegal for a woman to deliver a baby without help, or for her husband or partner to help her deliver. That’s why, officially, I am listed as having delivered my son, even though I paid an illegal crew of midwives to help me. (They were great, BTW.)
Now that I’ve identified alternatives, I can ask, is it possible that the alternatives are better than the proposed “best practice”?
- Is there a way to measure the quality of the practice?Without a scale and a measuring instrument, the concept of “best” has no meaning. Therefore, I’d like to know how to measure the value of not understanding a problem before I solve it.I don’t have much of a method for doing that. I’m kind of scratching my head about how to assess the value of understanding a problem, versus the value of, say, avoiding understanding. According to dead poet and methodologist Thomas Gray “Where ignorance is bliss, ’tis folly to be wise.” Maybe his is a useful sentiment.
- Is there any conceivable situation, then, when I would rationally make the choice to behave in a way opposite to the practice suggested to be “best”?I can think of a few possibilities:
- If I am trying to score very high on a mutiple choice test under time pressure, and I don’t understand one or more of the questions, it may be a better strategy not to interrupt the testing process and seek to understand each question prior to giving the answer. It may be better to give the best answer I can, based on heuristics or cues that come from the structure of the question or the structure of the answers.
- If I am being tested on my ability to spontaneously draw correct conclusions, under time pressure, the whole point of the test may be for me to select a solution before I consciously understand it.
- If I am watching a magic show, it would be an insult to the magician if I tried to figure out the trick using all my faculties of understanding the problem. The purpose is to be entertained. Trying to understand too much about the “problem” represented by each trick might spoil the fun.
- If I am a novice under the supervision of a master, and the master has specified how I am to select solutions in a particular domain. Even though I may not understand the problem, I still may need to follow the instructions as to the selection of solutions. The key thing, here, is that I am not taking responsbility for the quality of the work, only the quality of my following of instructions.
Do you know what’s behind all this? I think it’s simply that so few of us know how to do our jobs. Like puffer fish, many of us feel that we need to huff ourselves up so that predators won’t devour us. We fluff ourselves full of impressive words. But when I do that I just feel empty.
August 5th, 2006 at 11:25 pm
I would suggest that there is at least one practice which ALL Developers everywhere over the world need to follow all the time:
[James’ Reply: I don’t need to see your idea to know that it can’t fulfill the claim you made, above. What does “all the time” mean? What does “all developers”? Have you really considered what ALL means?]
Test Early, Test Often. I know enough people that don’t test at all that this isn’t just a way of life, and they NEED to have it drilled into them.
Otherwise, good article.
[James’ Reply: So, if I develop a sandwich, I need to test the sandwich? How much should I test it? It’s a bit like Zeno’s paradox, isn’t it? I will never eat the sandwich because I am never done testing the sandwich.
As you come to understand testing, you come to understand the impossibility of complete testing, which leads then to the necessity of making tradeoff choices. These choices are very interesting! Telling someone they must test all the time does not help to highlight the choices that must be made.
Also, I have to mention the other big issue in your idea of a practice: “Test Early, Test Often” is not a practice. You have specified, intead, an amorphous family of potential practices. How early is early? How often is often? What is testing? I don’t know what to do to follow your “practice”. I don’t know how to avoid screwing it up. If this is an acceptable statement of a practice, then why not simply say “Be Virtuous”? After all, virtue is a catch-all. If people just “did the right thing” they would obviously do the right testing at the right time.
We don’t exhort people to be virtuous, because it is not helpful advice. I submit that test early, test often is also not helpful when offered as a commandment. It is more helpful when offered as a heuristic, which is not in any way the same as a best practice.]
August 7th, 2006 at 2:56 am
Hi James:
Thank you very much for raising this concern: really, I agree with you that these best practices are hardly the best. The way that I see it, though, is that we cannot create best practices that are this concrete. “Test Early, Test Often” is too concrete to be considered an all-around best practice. I do think, though, that given a specific context, it is a best practice. I think the problem comes in with all of this is that these practices depend too heavily on context to be best.
[James’ Reply: When you say best, you don’t mean best for other people, do you? Because if you are saying that other people should consider it a best practice, then A) you must specify an actual practice, which you haven’t done, and B) you must demonstrate why ALL alternative practices are worse. You haven’t done that, so your statement is rather like saying “Star Wars is my favorite movie”. It stands on its own as a somewhat vague statement about yourself.
Whatever you think testing early and often means, I understand that it’s your favorite practice in some context. It would be more helpful to me if you told me what specifically the practice is, and what about the practice and potential contexts makes you desire it.]
I realized that my comment to you would be both very long and possibly beneficial to write about on my blog, so I did just that. If you get a chance, take a gander at my website and read the latest article on best practices. (And feel free to quote me on here if you feel it relevant.)
Thanks again for the great post, you really got me thinking about how I’ve been teaching my subordinates about *good* practices.
M.T.
[James’ Reply: I’m happy to help. Consider saying “my favorite practices” or “practices that have been useful to me” or “appropriate practices”, instead of “good practices”. Since no practice is good or bad in itself, the alternative phrasing helps keep people straight.]
August 9th, 2006 at 2:14 am
No practice is good or bad in itself? That’s some claim.
“Always code as if the person who will be maintaining your code is a psychopath who knows where you live.” That one seems pretty good to me - I can’t think of anywhere where it would be a dumb thing to do (Yeah, IOCCC, Perl Golf/Obfuscation games, but those are pretty artificial sets of constraints)
[James’ Reply: First of all, it’s not a practice. How can you even start to talk about bestness if we don’t know what the practice actually is? If I followed the advice in the statement you offer, I would do vastly different things depending on how I feel about psychopaths. If I took it seriously, then I would probably not let anyone maintain my code, ever. Is that the practice you were thinking of?
Secondly, you haven’t mentioned an obvious context: prototype code. Most of what I write is throwaway code for my own use. I write programs to solve logic puzzles or create test cases. My focus is simply not on maintenance. Sorry, I don’t care. It’s very rapid coding to solve ephemeral problems.]
“Name all your instance variables using the scheme instanceVarOne, instanceVarTwo, …, instanceVarOneHundredAndTen. Variable names should be globally unique within your module, so Class A would have instance variables 1 through 10, and 26 because you realised you needed it later in the project”. Modulo the places where the ‘psycho with your address’ practice is a bad idea, this one looks like a seriously dumb idea.
[James’ Reply: We can certainly identify practices that seem uninteresting or problematic in many, many contexts, including all of the context we expect to find ourselves in. But, why bother? That would be a little like trying to give a unique name, like “harry” or “fred” to each number. We don’t need to do that because we have a scheme that lets us create a name on the fly. Similarly, I don’t need to memorize good and bad practices, because I am able to consider each practice afresh, whenever I arrive at a problem I want to solve. I cache my answers, of course, so that I don’t need to rethink every little thing when my context hasn’t changed since the last time.]
Books like ‘Smalltalk Best Practice Patterns’ and ‘Perl Best Practices’ all make a point in their introductions of pointing out that they are collections of practices that the authors have found to be of utility in their own programming practice and they may not be universal. ‘Best Practices’ become poisonous when they become dogma - a very important part of understanding any pratice that is presented as good, best, or whatefver, is to understand the reasoning that leads to the practice’s recommendation. Even if you reject a proposed practice, the very act of thinking about the idea has value.
[James’ Reply: Yes, that is exactly what I want to promote. Also, I want to promote learning from each other, and that gets easier when we go into the conversation in full realization that our contexts may differ so much that our judgments of good and bad practices will likely conflict.
I wish the Extreme Programming people had that attitude. Apparently the “extreme” stands for “extremely unwilling to reconsider our practices” to hear some people talk about it. (Note: Ward Cunningham does not have that problem. I haven’t met Kent Beck, so I can’t comment on him. It’s the followers that I have trouble with.)]
By the way, you appear to have italicized a passage of MT’s response so that it looks like it’s your reply to him.
[James’ Reply: Thanks for the report. That turns out to be a bug in Wordpress. I found a workaround, though.]
August 23rd, 2006 at 7:24 pm
Your premise is a breath of fresh air. Best Practices has become a defacto Holy Grail even outside the software industry. I try to impart the concept that there are Best Practices Templates to guide corporations towards preservation of knowledge.
January 20th, 2007 at 12:47 am
Hi Stuart,
I totally agree with you. Many best practices fail or remain on paper. All practices are context drives and context are rarely the same.
Eg. The best practice to preserve food is a refrigerator in US but is it the same in iceland or an african village without electricity.
Many best practices that IT vendors profess to their clients are not practiced themselves. Eg. ERP systems are not popular among IT vendors - even those that market them.
People who profess best practice very rarely show lower practices being used in the same context. it’s like claimimg to win in a one man race. managements use these gimmics to boost the confidence of professionals who they drive to over extend themselves - mostly software professionals (where rework is over 60% but not openly recorded or spoken about).
Most people try to run with the crowd and hence the popularity of the word ‘Best Practices’ at conferences and seminars.
Another point is that best practices means ultimate practice - hence no improvement is possible - people professing best practices would have reached their level of competence.
Regards
Alan
January 24th, 2007 at 9:10 am
Secondly, you haven’t mentioned an obvious context: prototype code. Most of what I write is throwaway code for my own use. I write programs to solve logic puzzles or create test cases. My focus is simply not on maintenance. Sorry, I don’t care. It’s very rapid coding to solve ephemeral problems. A?…
July 23rd, 2007 at 4:54 pm
Great post.
Here’s a good counter example to the “seek to understand your problems..” thingy (I’m posting this because all your original counter arguments revolved around non-development tasks):
Let’s say I faced an odd behavior while doing development on a framework. I do a bit of Googling and find out that the framework vendor has released a service pack that solves the exact problem I’m having. I do as I am advised and, whaddayaknow, my problem vanishes.
Now, suppose the reasons behind that problem is rooted in some kind of OS kernel arcana about which I know s**t. Do I seek to understand that problem, risk missing my deadline, and waste precious brain cells on knowledge I won’t have any use except for small talk during coffee breaks?
Or do I just install the damn service pack and move along?
[James’ Reply: The answer depends on the nature of your problem. Sure you are not telling me that you CAN’T IMAGINE a situation where you would NOT install the service pack. I can think of a few. You may be in a situation where you have a golden master and you don’t want to install any changes except exactly what is needed to fix the problem. It is not a “best practice” to install service packs. It’s just a practice, and apparently one that you like (I like it, too). Perhaps if you have some bad experiences with service packs you’ll decide that they aren’t infallible.]
February 18th, 2008 at 6:26 am
Hopefully not all idiomatic expressions get this much attack.
An idiom is an expression, that is a term or phrase whose meaning cannot be deduced from the literal definitions and the arrangement of its parts, but refers instead to a figurative meaning that is known only through common use.
This applies to the term “best practices”, too. It is not exact code, it is just human language
[James’ Reply: I dealt with this objection in my post, already. “Best practices” does not make sense as an idiom or as a literal phrase. It’s just plain sloppy and/or manipulative speech and we should not engage in it.]
March 23rd, 2008 at 8:30 pm
It doesn’t matter if the “best practices” are really best or not. “best practices” is only the name we use to call them, ok, maybe it’s a bad name but the important thing is that they teach you something, even if you don’t agree with them.
[James’ Reply: If it’s a bad name, why are you using it? What is your motive? The only motives I can think of are dishonorable. And you can learn from any practice, even a bad practice. You can learn from anything even if it’s not a practice. Learning has nothing to do with it.]
Knowing them is the important thing. They increase the knowledge you need to be good at what you do.
[James’ Reply: No. Knowing them as OBJECTS is not the important thing. Skill is the important thing. Being able to solve problems is the important thing. Collecting labels and rumors of practices, as if they were trading cards or something, does not make you able to do anything better.
I definitely study how problems get solved, but I do think in terms of practices, except as a linguistic convenience. Neither should anyone, I believe, unless their goal is to be a successful fake who can speak buzzwords but not solve problems.]
The value best practices have is that they are things that some people think are important in most situations of a certain kind. That’s enough to consider them and to know them.
[James’ Reply: I just made an argument that there is no such thing as a best practice, so your sentence is meaningless to me. You might as well say “the value of unicorns is that they improve the color of rainbows.” You can’t point to any practice and call it the best, therefore what you must mean is that you believe you have found certain practices to be useful in certain contexts. If so, then you must know why they are valuable, and you must know how they can fail. Talk about that, don’t just tell me it’s important to study that practice for some mystical reason that you can’t explain.]
They may be right, they may be wrong, the final decision is always yours, but knowing them is good.
[James’ Reply: Knowing WHAT is good? You aren’t referring to anything. This is part of the reason why “best practices” is incompatible with competent engineering discourse. Many managers think they are offering sage advice when they suggest we go and find “best practices”. They might as well ask for the Holy Grail. It’s childish. Let go of the whole idea, please.]
I think the problem arises when someone justify a decision only because it’s based in a best practice. This would be an authority fallacy, concrete reasons should always be given.
[James’ Reply: I’ve given you concrete reasons why there can be no best practices, but that hasn’t helped much, has it? You can make yourself impervious to reason, if you want. People do it all the time. But how about trying to answer the arguments I made in my post, instead of ignoring them?]
March 23rd, 2008 at 11:55 pm
What James is trying to convey it true and very valuable. People mostly find some practice effective in some context and take it to granted that it can be applied to a universal range of scenarios. Unfortunately this is encouraged by organizations which want to impress the immature clients that they have a strong range of expertise by showcasing their best practices. The problem is people most of the time blindly follow what others advocate as best practice.
I hope people will be disillusioned about best practices and value skill and knowledge more. I am not sure but I hope we can have the practices aligned with their context and before we suggest any practice to a problem we will study that problem rather than blindly advocating it. We can learn this from the design patterns community. Every pattern will have a motive and context associated with it. So if we encounter a similar context we can think about applying a pattern to the problem.
[James’ Reply: I think you get it. Cool.]
March 24th, 2008 at 11:05 am
OK, I think I get it too. You’re declaring “No Best Practices” a best practice, right?
[James’ Reply: Not even that is a best practice! Can you think of a context where it may be a good practice to believe in best practices (or at least to affect such a belief)? I can. None of them are contexts I would like to work within.]
March 30th, 2008 at 1:36 pm
It’s too bad you hide the interesting points of your article, which would be context matters and think for yourself, between trying to argue what people really mean when they use the expression best practice.
[James’ Reply: I think the strongest argument against “best practice” as a phrase is that it’s bullshit, the only purpose of which is to artificially and deceptively inflate one’s ideas. To me, that is the most interesting thing: don’t speak bullshit if you want to be taken seriously by serious engineering thinkers. Knowingly sloppy talk about methodology is a popular refuge for bad work in our field.
I haven’t argued that imprecise speech is always bad. In at least one other post I’ve argued that it’s necessary. It’s the manipulative usage of that particular phrase I find contemptible– and there’s no other motivation to use it I can see except to manipulate the ignorant.]
April 2nd, 2008 at 5:32 am
I agree that “best practice” as a judgement is decisive and generates conflict.
In order to decide which is the “best practice” for a context, you really need to know the skill/practices. In which case, you had “best practice” with the skill/practice so that you know whether it works or not. It is not allways a good idea to try out a new idea on the critical path.
Unfortunately a number of people think that the best practice is the one they know and they do not need to know any other approaches. So then, a you “best practice” this skill if you want to be part of the decision process as to whether we use it or not would be appropriate.
My “best practice” is that people should learn and become proficient in as many appropriate skills as possible rather than become the ultimate master in one or a few skills. It is quite interesting that many early adopter agilists know more about the waterfall process than the waterfall proponents. They had to be to have the arguments. Sadly many second gen agilists do not understand the traditional processes and are operating based on belief rather than knowledge and experience. The problem with this is that it limits to art/craft of software development.
[James’ Reply: Have you read the Book of Five Rings? Sounds like you have.]
April 3rd, 2008 at 6:39 am
But, but… Version Control is an absolute best practice. No questions. No discussions!
April 4th, 2008 at 7:02 am
Sorry Aaron.
Some of the projects I’ve worked on, it would have been a positive blessing if we had lost the source code …… All of it.