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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 aminfluential 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.

  1. 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.
  2. Does the advice involve a meaningful distinction among possible behaviors?The more you try to specify something that is alwaysbest, 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”?

  3. 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.
  4. 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.

38 Responses to “No Best Practices”

  1. Danno Says:

    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.]

  2. Matt Todd Says:

    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.]

  3. Piers Cawley Says:

    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.] 

  4. Arne Antos Says:

    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.

  5. phentermine 37.5 mg Says:

    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.

  6. alan Says:

    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

  7. Ishmaeel Says:

    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.] 

  8. Martin Makundi Says:

    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.]

  9. Daniel Cadenas Says:

    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?]

  10. Sai Says:

    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.]

  11. David Peterson Says:

    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.]

  12. Jean-Francois Couture Says:

    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.]

  13. Chris Matts Says:

    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.]

  14. Aaron Says:

    But, but… Version Control is an absolute best practice. No questions. No discussions!

  15. Chris Matts Says:

    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. ;-)

  16. Vid Says:

    Instead of saying that there are “no best practices” can we not say that “all practices are best”? After all, no individual practice will be identical. If I was to say that a best practice is to “evaluate use of automated testing”, is there any practise better than this? The only argument I can see against this is a time constraint, but there is no rule to say that a ‘best practice” has to applied at any given time?

    [James' Reply: "Evaluate use of automated testing" is not a practice, it's an aspiration. There's no practice in it.

    It's not helpful to treat such empty statements as practices. To see why, add a word. Say "Excellently evaluate the use of automated testing." Isn't that a better statement? If so, than the first statement could not have been "best."

    If you ASSUMED that automated testing would have been done excellently, then why not replace that practice with this one: "Plan the testing?" Surely, planning the testing includes evaluating the use of automated testing, if it is to be done excellently.

    But if it's okay to assume excellent work, then go all that way with it and simply say "Do great work."

    None of these are practices. None of these are particularly helpful, let alone "best."]

  17. Vid Says:

    Ok, I can see where your going with this, but I think we are talking about different things. “Evaluate use of automated testing” is a practice, it is a procedure that I can repeat on every project. Furthermore, it is a procedure, that I would want to apply on every project, so I would call it a “best practice”.

    [James' Reply: Whether you call that a procedure or a practice, I think it makes a mockery of our craft to do so. It's simply vapid. It tells us nothing. It's not repeatable in any interesting way. Someone who is incompetent and someone who is highly competent can both perform such a "practice" and get profoundly different results. In the case of the incompetent person, the "practice" will certainly lead to bad decisions and wasted time and money.

    I wouldn't want to apply it to every project, even as stated, for obvious reasons (a project that lasts 60 minutes, for instance, may not require an evaluation of automated testing. A project that has already been standardized on a tried and true methodology may not require it, either.) But my principle objection is that it is, in fact, not a practice, but rather nothing but a reference to an unspecified activity.]

    “Excellently evaluate the use of automated testing” is not a practice, it is an aspiration. Perhaps we can differentiate between the two statements by saying that your statement is the “application of the pracice”?

    So to sum up, I believe there are “best pracices”, but there is not a ‘best way’ to apply them practices.

    [James' Reply: I'm afraid this is a perversion of the ordinary meaning of the word "practice". But even if we accept it, you have offered no reason to say that the "practice" you've suggested is in ANY WAY better than any alternative.]

  18. Brian Says:

    Best post I’ve read in a very, very, long time, it’s a shame it took over a year to stumble across it.

    This summed it up for me:
    In my maturity model of the industry, promoting a maturity model is mere level 2 behavior. By level 3, we outgrow it.

    I mean when you reach that point from being the preachy know it all where everything is ‘by the book’ and ‘best practices’ and ‘I wouldn’t recommend’ and ‘I strongly suggest’ to just accepting that nothing is ‘best’ and ‘context/relevance’ is they key a light goes off and you read this article and you’re like ‘yeah’.

    And then you read these people arguing the point (level 2 guys) and think to yourself ‘hey I once was like that – imagine that’ and just shake your head and walk away. The shame of it is that you have to go through level 0, 1, and 2 first before you realize (as the kind in Matrix said) that ‘there is no spoon’.

  19. Doug Says:

    Congratulations on stirring the pot.

  20. Boo Says:

    I came here accidentally, but the post was intriguing so I stayed a while. I see many similarities between how education (my field) uses the term and how your industry does.

    If behind every job or project or problem you substitute a child your arguments become everything I feel when I am given some universal rule of the thumbiest. Options are very important but the kid decides the flowchart and to pretend otherwise puts the kid at risk.

    Or maybe I don’t get it. :D I am just really tired of how that term can perk up ears.

    [James' Reply: Education is about to become my field, too. My new book is my attempt to counter the "best practice" of going to school.]

  21. Boo Says:

    Then I will have to read it. I am ridiculously curious about what you suggest in place of traditional ed. specifically public ed. There have to be better more meaningful ways. Trying to find them myself, and as a cog in the system it’s complicated going.

    Found the Buccaneer blog and site and have bookmarked for further reading. Nice to meet you and a kind of relief too.

    [James' Reply: Are you familiar with Summerhill? Basically, I would suggest an end to lies and coercion, assuming anyone cares what I think about public policy. But they don't. So I don't cover that in the book.

    What I cover in the book is what I did to educate myself... and what I did goes against most of the classic advice about how to study. For instance, I had no particular plan and used no particular discipline, yet my approach to learning seems to have worked pretty well.]

  22. David Nelson Says:

    Very interesting analysis. Unfortunately, the entire post is based on a misunderstanding of the word “best” in the context of the phrase “best practice”. It does NOT mean “better than all other practices in ALL contexts”.

    [James' Reply: I think I did and do understand what it means. I think it's just lazy and wishful thinking masquerading as reasoned judgment. But if someone perverts the language to mean what you say it means, I would apply the same logic to unmask it.]

    Rather, it means “more likely to be correct in any given context than any other practice”.

    [James' Reply: Don't you see that is just as unobtainable and unreasonable a standard as "best"? How could you make such a claim about any practice? How do you know what my contexts are likely to be?

    The view of best practice that you propose still is, at its heart, an attempt to be a backseat driver of someone else's process. Worse, than that-- a blindfolded backseat driver.]

    It is important to understand that this term only applies when there is not enough information or understanding to choose between practices on their own merits (which happens a lot). Basically, its like saying, “if you have to choose between all of the available practices, and you don’t know which one to choose, this is the best one to choose.”

    [James' Reply: If that's what it means, it constitutes reckless behavior. Please don't reduce engineering to blind trigger-pulling.

    To be prudent, instead of reckless, you have to be present in the context and sufficiently skilled, or you have to specify enough about the context and the practice to convey the relationship between problem and solution to the practitioner who IS in that context.]

    Now I can guess how you are going to respond, based on your post: developers shouldn’t be choosing practices if they don’t have enough information or understanding to choose them on their own merits.

    [James' Reply: Not quite. What I would say is that if you don't have information and understanding then don't LIE TO YOURSELF AND YOUR CLIENTS by pretending that you know what's best, or even what's good.]

    And in an ideal world, I would agree with you. In an ideal world we wouldn’t need best practices. If you discover that world, let me know.

    [James' Reply: Oh stop with the "real world" talk. That's not an argument. I'm no arm chair theorist. Look at my CV on my website, if you want.

    I have not used the concept of "best practices" in my work, nor have I taught it, since I first recognized it's vacuousness in 1998.

    Try living without it. You'll find that you can.]

    But back here in the real world, developers have to make decisions that are above and beyond their own knowledge and abilities every day. When that happens, they are much better off choosing the “best practice” than any other practice; it may not necessarily be the right practice for their situation, but it is the best choice because it is more likely to be right than any other choice.

    [James' Reply: You seem to be speaking of heuristics. And for some reason you seem to feel that a heuristic that has been blessed by convention is an appropriate substitute for skill. I just don't live that way. I don't need to. Neither do you.]

    For example, in chess there are a number of best practices that are taught to beginning players. “Develop knights before bishops” is a good example. It is generally good advice because knights can be developed sooner; they can jump over pawns, whereas bishops have to wait for the pawns to move before they can move. Knights are also short range pieces, so it is important that they be close to the action; bishops are long range pieces and don’t need to rush forward as fast. That said, they are certainly a great many situations where developing a bishop before a knight is the right thing to do. The problem is, a beginner (or very often even an intermediate or advanced player) may not be able to recognize when such a situation occurs. In those cases, what should the player do? I would tell the player to rely on the “best practice”; yes, there is a chance it might be wrong, but it is more likely to be right. Would it be better if the player had the understanding of a grandmaster and could recognize for himself in any situation which is the right thing to do? Of course it would. But he doesn’t have that understanding, and he is playing in a tournament this weekend.

    [James' Reply: I play a lot of chess. (I'm "satisfice" on chess. com) I think differently about chess than you do. When I teach chess, I also give general principles. But I don't tell people to "follow" them. In fact, we violate them and see what happens. You are never going to win a chess game against a good player (except if he blunders) by relying on best practice thinking. You must understand the moves and the patterns. You must reason.

    I would probably accept many of the principles that you would recommend, but my relationship with those principles is not one of "follow in ignorance", but rather one of conscious understanding and application. I work with students to develop that understanding, which happens by playing a lot of games and reflecting upon them.]

    I appreciate what you are trying to say, and I certainly agree that the term “best practice” can be erroneously used to “impress the uninitiated.” But that doesn’t mean that the concept has no value.

    [James' Reply: I argue that the concept has negative value. It softens our brains. Look around! It's a meme that opposes excellence. Replace it with "I don't know what's best. Let's try this idea and see what happens." You'll find that you get all the value you thought were getting from "best practices" without the puffery. Puffery opposes learning.]

  23. Skip Pletcher Says:

    Four years later you still receive comments. That says something about the level of interest, perhaps more than a 22 comments in 4 years ration would.

    [James' Reply: I think lots of people are interested. Not so many want to submit themselves to my editing! Thank you for playing.]

    I happen to agree that there are no best practices; continuous improvement would cease if there were. Even so, I would prefer that practical thinkers (who know better) continue applying the phrase “best practice” to their products (or at least to search terms) because they simplify my googling for better practices.

    [James' Reply: So you would find it difficult to learn about practices without a guiding adjective? That's the first time I've heard that argument. I'll make a new entry in the wacky reasons list. For me googling is not the primary way I learn about testing practices. Mostly I learn by testing, talking to testers, watching testers, reading blogs by testers whom I trust. That's gives me quite a lot of material.]

    Need we banter for years over semantics? If so, attack a more valuable target. … like “Testing”

    You referred to “Testing” as an intellectual craft. Testing is not a craft, intellectual or otherwise. Testing is a gerund for a measuring activity — an activity which can easily be automated — there is certainly no intellectual craft in a computer blindly executing measurements.

    [James' Reply: That's an odd thing to say. Well, I recommend the Oxford English Dictionary for a comprehensive treatment of the word "craft." What I do in testing, over the last 22 years, and what I teach in my classes, is obviously a craft of software testing. I prefer the word craft to art, because it connotes a little more of an engineering bent.

    Regardless of whether you think it's a craft, there is no controversy about this except, apparently, with you. If you want to argue that it not a craft, you'll need to make a much more compelling case to give me something serious to think about.]

    Since you termed it an intellectual craft, the meaning I presume you apply for “testing” employs a similar semantic ‘sloppiness’ which results in a phrase like “best practices.” To do so is not sloppy, it is shorthand. We say ‘testing’ when our meaning is feature analysis, test design, test planning, and a host of related phrases which must occur to craft a test suite of value.

    [James' Reply: I see no semantic issue, here. The craft of testing obviously includes a wide variety of activities. Just as all crafts do. What exactly is sloppy about that? When we speak in language we use words to represent things. My use of words in this case is ordinary, non-confusing, and consistent with the dictionary. You could argue that different people include different things in the craft of testing, but that's not a sloppiness issue, simply a difference of context, community, or philosophy.

    The sloppiness of "best practices", on the other hand, is insidious and damaging and totally unnecessary. Use that term and you lose credibility with people who take their ideas about excellence seriously, as I do. Why not say "practices I find interesting?" It's easy. Why even argue about this? You don't mean best practices. You gain nothing from saying it. You confuse people by saying it. So cut it out, man.]

    The shorthand becomes dangerous only when and if it results in the sort of effects you described. Calling practitioners of your craft ‘testers’ can (and does) cause them to see themselves as workers who execute tests rather than thinkers who design them. Similarly degrading the consideration afforded by their teammates who call themselves ‘developers.’

    [James' Reply: I haven't seen that problem. I'm a tester. To me-- and to lots and lots of other people-- that means I test things. This is far more than "running tests" especially since I don't see testing as an artifact-centered process. Perhaps you come from a very different corner of the field than I do.]

    Do the ‘testing’ craft a favor, come up with a better shorthand symbol.

    [James' Reply: What do you recommend?]

  24. Michael M. Butler Says:

    Skip Pletcher writes: “Testing is a gerund for a measuring activity — an activity which can easily be automated — there is certainly no intellectual craft in a computer blindly executing measurements.”

    Mr. Pletcher, your meaning for the word “testing” /is/ a sterile subset of the actions taken by a skilled person, that is true. Nonetheless, in the time I have worked in the field I have disproven the claim that asked-for “measurements” could be easily automated on many occasions. The ones that were easy to automate were mostly not the interesting ones. Performance testing changes this marginally, I admit. Often my most valuable testing results were not things the stakeholders ever asked for explicitly.

    Also, some key problems with the model you propose are, /observation is not measurement/, and neither is meaning. Tell me the measure of “That ATM just ate my card.” Tell me the measure of “The anti-lock braking system just put itself through a hard reset and rebooted while the car was airborne and our prototype vehicle is wrecked.” Then tell me the measure of an automated test case result which is not meaningfully interpreted by some human.

    I don’t work much in the field these days, but if I did get back into it as a day job, instead of a tester, I might call myself an objectives-oriented software systems critic. Criticism still hasn’t been [claimed to be] automated just yet.

  25. Christian Paredes Says:

    James,

    I really appreciate your post. I’m not in software testing but I am in IT as a junior sysadmin; I don’t have much professional experience myself, so I’m still trying to adjust my eyes to the waking world of IT buzzwords and bullshit that goes around. I’m still holding onto the hope that I can immerse myself once again in the academic world with like-minded sysadmins.

    I’m wondering if you’ve read a lot of philosophy in a past life? I’m always wondering if Wittgenstein is rolling violently in his grave as the field of IT is further “advanced” with terms that are referring to absolutely nothing.

    Anyway, thanks again for this post, it gives me a bit of hope in this occupation.

    [James' Reply: Yeah, I enjoy philosophy. I consider it a survival skill for senior testers.]

  26. Geber Says:

    Test Driven Development is a “Best Practice”.

    [James' Reply: Says who? You? Do you speak for the universe? Do you have a mathematical proof of this, or do you get by on a lack of imagination? Can you cite any comparative study of practices? Can you tell me what exactly test driven development is, because I know what *I* mean by it, but I don't know whether you are talking about the same thing that I'm thinking. Are you aware that there are different contexts in which development occurs? Can you identify any of those contexts, or do you not feel it's important to be aware of the world around you?]

    If you are new to software development, please learn test driven development. The best developers I have worked with have all done test driven development. The worst developers I have worked with have all shun test driven development.

    [James' Reply: Ah, so when you say "best practice" you mean "practice that I like." Why don't you just say that?]

    If there is one thing, and I mean one thing the software industry has done right, it’s the promotion of test driven development. It’s outright irresponsible of James to write otherwise.

    [James' Reply: I think we see our responsibilities differently. I see my responsibility as promoting critical and scientific thinking about technology. I don't know what you are up to-- but I understand that you like what you call "test driven development" and that's okay. When you want to claim that we should stop thinking and just do whatever you tell us to do. I say go to hell.]

  27. Dudley Says:

    I work in a science museum (informal education). As a newcomer to this field I find the term “best practices” in just about every document that is produced by ALL departments – exhibit development, museum programming, research/evaluation, even the design/creative department. It’s a completely backwards thinking model that sadly says:

    “I have no confidence in myself, my team, or what my institution claims to stand for so I have to look at what everybody else does and says in order to make any decisions.”

    and this is suppose to be a creative, fun, informal way of presenting science.

    Another word that should be destroyed in “creative” fields: Protocol

  28. Samuel Says:

    James,

    If in a team each tester practices his own favorite practice instead of what the lead or the manager wants them to do, there would be chaos.

    I agree with all that you say but I see the above problem if every person were to practice what you have to say.

    I think in a particular project there should be only one practice that everyone should follow, if some one wants to deviate there should be a sound reason.

    Your thoughts?

    Sam

    [James' Reply: My thoughts are that you have completely missed the point of this article. You seem to think I am arguing against teamwork. You seem to think I am following some doctrine that blindly promotes chaos. What I have to say is that we must look at the situation and solve the problems we find there, RATHER THAN to blindly follow what other people, who are not in our situation, have declared to be generally "best" or even "good". If everyone did what I am saying within the scope of his responsibility the word for that would not be chaos, but rather ENGINEERING.

    You think there should be one practice that everyone should follow? I've been doing this for 28 years, as of this month, and my experience doesn't lead me to think technical life is a matter of following "one practice." I wonder why yours does? Why make such pronouncements as "there should be a good reason to deviate?" What do you think that buys you? Why not simply say "act reasonably within the scope of your responsibility?" And if that mean people deviate from whatever, then so they do. If that means they don't, so they don't.

    I don't drive a car by telling myself there should be a good reason to deviate from the "normal" case of driving straight ahead. And neither do you! You do not drive based on aphorisms and pronouncements memorized in advance. You just apply your skill and do what is needed.]

  29. Erik G. H. Meade Says:

    Best Practices are appropriate for use in the Cynefin Simple Context. http://en.wikipedia.org/wiki/Cynefin

    [James' reply: That's a beautiful example of appearing to argue by use of magical incantations.]

  30. Lisa Says:

    I LOVE this article. I am not in the computer business, but in my work as a teacher I have been subjected to meetings with consultants who use the phrase “best practices.” It is always followed by time-wasting bullshit.

    [James' Reply: The phrase is used by bullies to intimidate, by dilettantes to impress, by cowards as a shield, or by the apathetic because they copy and paste their words from the surrounding landscape.]

    I have to meet with a consultant on Monday who was hired by an arts organization I work with. She already spent one of the two hours she’s being paid for telling me what we could do in the second hour, though there was no earthly reason we could not settle down and do the actual work during the first hour. I’ll bet there are consultants who give valuable information to their client organizations, but I haven’t met one yet. So far I’ve only encountered people who can talk about talking about work, which takes time from actually working or learning. I know that’s not what your post is about, but it seems this phrase is part of a layer of jargon that is not about actually getting work done or gaining valuable insight into how to work better. When I asked myself what would take the place of “best practices,” I thought, “learning a skill.” I actually googled “best practices + bullshit” to see if anyone else was bothered by this phrase–that’s how I came across your article.

    Plus, there’s something ugly grammatically about saying, “it’s a best practice.”

    [James' Reply: Thanks for stopping by.]

  31. Peter Sellars Says:

    I have been struggling with “best practice” a lot lately as most don’t take any context into account. Contextual understanding of dealing with a problem can lead you to suggested/recommend solution which need to be tailored for the specific situation.

    I don’t really believe in “best practice”, but do have practices I would use in various situations tailored and taking into account the context. I am currently looking into rapid deployment contexts and looking to propose some considerations that may be suitable in this area – but not recommend them as “best practice” or a “model/strategy”.

    For me all practices are about “Shu-Ha-Ri”. Learn about a practice, Learn from others and practice what you learn then you begin to adapt and use the practice in situations you feel it applies. The final stage of is alluded to clearly by James in this well articulated article.

    [James' Reply: I don't get Shu-Ha-Ri. It implies that you learn things by rote before you explore and experiment. That's not how I prefer to learn, nor is it how I teach.]

    As we become better at our crafts and understand the context we are able to leverage groups of practices to get the results we require, and share how the practices we worked in this context – and should stress, in this context.

    My current focus on rapid deployments leads to groups of practices related to CI, Release Management, Testing etc. I view rapid deployment as a way to alleviate risk, improve quality and as an enabler to deliver more business value in our solutions. I can make recommendations, but there is no “best practice” for me, there are practices recommended for certain situations, but ultimately teams implementing solutions need to understand the choices and pick the one that delivers the outcome required.

    Interested to hear from anyone else and what “best practices” they are following and how this article resonates with them….I am strongly in the contextual implementation of a solutions (using all the tools in my toolkit: practices, experience, contextual understanding, expected outcomes etc) rather than following a method/strategy because thats what people say. ‘Be agile’ rather than ‘Do Agile’ etc.

  32. Per Viberg Says:

    I agree 95% with the article. I say 95%, because the 5% exception is that “Best practices” are actually good for beginners, (and ONLY for beginners). Beginners have to start with “best practices”, because they don’t know where to start.

    [James' Reply: Best practices don't exist, so your statement has no meaning to me, as is. Perhaps you mean there are practices that a knowledgeable person might suggest to a less knowledgeable person that may help them. I think that is true-- in some contexts-- but that hardly qualifies for the phrase "best practice." Why not just call that a suggestion? Or call it "advice."

    Here, let me demonstrate: My advice to you is that you avoid calling anything a "best practice." If that doesn't make sense to you know, do it anyway-- someday you'll learn why there are no best practices.]

    A beginner may come with a “best practice” advice to me, and I will sigh, because I know that that “best practice” may very well work in 95% of all cases, but on this one it doesn’t. Why I sigh is, because I know that I will have to explain to this beginner exactly why it doesn’t, and that amount of energy and time it will take to convince this beginner… *sigh*. You get the idea.

    [James's Reply: That's exactly how I feel right now. Dude: there are no best practices. But if you think there are, you need to answer the arguments in this post.]

  33. Andrew Says:

    Great article and I agree with what you are saying, too bad their are people in the industry who still try and buy into “buzz words”. Every time I hear someone I work with or know use this phrase I loose a small amount of respect for them as it cheapens what they are are trying to say.

  34. Oscar Says:

    I agree 100% with everything you’re saying here, and searching the web for people with the same ideas is what led me here.

    However, I’ve dedicated a lot of time about finding counterpoints to these points. In particular, finding a context in which “best practice” makes sense. No easy task, since of course, nothing can be best for all cases.

    [James' Reply: I'm wondering why you WANT to find such a context, other than as an intellectual exercise. I mean, why not just say "I like this practice?"]

    Nevertheless, the closest I’ve gotten to a valid use of “best practice” is in the context of “this is a technology we made, and this is how you use it. Therefore we define the best way to use it”. I would like to know what you think about it.

    Take for instance this whitepaper: “Best Practices for Creating DLLs” located at http://msdn.microsoft.com/en-us/library/windows/hardware/gg487379.aspx

    [James' Reply: That is a pretty good example, compared to almost any other I've seen. Here's what I'm left with: Why say "Best Practices" at all? What exactly does Microsoft gain from that? Here's how I would title such an article: "Creating DLLs" (Look Ma, I used three fewer words!)

    Another issue is whether these are, in fact, the very BESTEST of practices, or simply the ones they want me to use. It's a good argument to say that they are best practices if they constitute an agreement that must be maintained for the safety and security of all. But even that is conditional on that context. For instance, you could say it's a best practice to drive on the left side of the road in the UK, but on the right side in the USA. Or you could just say it's "the practice."]

    I would have used a less controversial title, like “how to make a DLL that won’t make your life a living hell”. But all of the “best practices” they mention in that whitepaper are quite good, and I can’t think of situations where you would want to deliberately go against them.

    [James' Reply: In that very technical context, I don't get upset with the term. I do get upset when it's used in a very open-ended context where in fact plenty of valid and different ideas exist for how to do the same kinds of things.]

    In other words, if you don’t follow the rules in that whitepaper, you’re wrongly using the technology, and not only your program won’t work right, but also it may not work at all in future versions of that technology.

    In an oversimplified example, it’s like: “best practices for adding two numbers: add, not subtract them”. In fact, when adding two numbers, the best (and only) way to do it is by adding them. Whenever you do something different, you’re not adding numbers, and there is no scenario where it makes sense to add two numbers by subtracting them.

    What do you think?

    [James' Reply: I think you seem like a thoughtful man.]

  35. David Robbins Says:

    You are my hero!! I can’t even count how many times I have heard very non-techincal, business process management types lecture me about best practices. They are incredulous when I say “Well, says who?”

    Don’t people realize that before the Wright brothers, best practices maintained that manned flight was not even possible? The earth is flat, right?

    Great post.

  36. Mark Camp Says:

    I think the following things, after perusing the thread.

    The topic’s important; everything you say about it is correct; you have given a carefully reasoned counter-argument to every proposed rebuttal to your proposition; many who disagree with you haven’t even bothered to address your counter-arguments; no-one so far has plausibly argued a contending position; you’ve struck a nerve because the specific topic you chose is so representative of a set of similar issues concerning destructive, dishonest patterns of social behavior which, collectively, are even more important (you’ve gotten a response from the teaching profession, for example.); you would get similar responses of passionate agreement from every part of society if all were exposed to your ideas.

  37. Cameron Haight Says:

    James – I am truly amazed that almost 8 years past the original posting date that your blog entry is still generating interest. I’m current involved in a project that I would love some of your “contextual advice” on. It is directly related to the content of this discussion. Please let me know the best way to get in contact with you. Thank you.

    [James' Reply: I will email you.]

  38. Rachael Says:

    Best Practice:
    Make your variable/table/etc names meaningful, and relevant to the business. If your names are technology-specific, then any future changes in technology to the business will require changes. If they are not meaningful to the business then future developers will not be able to quickly understand and identify the object.

    [James' Reply: Where is your evidence that this is best in your context? What alternative practices did you test? Did you personally experience those alternatives, or did you interview people about alternatives? In what contexts will this practice be irrelevant or harmful (I've been a programmer for a long time and I can think of some)? What do you think is gained by saying that this is "best" instead of saying that it is a practice you like? It may even be your personal favorite practice, but why call it best? Do you want to stop timid people from questioning you? Well, I'm not timid, so that marketing rhetoric is not so effective on me.

    I would also note that words like "meaningful" and "relevant" are indexical terms that nicely hide the actual practice you are referring to. In other words, what you mean is "this practice PLUS SUFFICIENT SKILL AND JUDGMENT WHICH IS SOCIALLY SITUATED TACIT KNOWLEDGE."

    My post is a serious attack on sloppy thinking. I would like you to read it carefully and address the arguments I make. Otherwise, you are simply providing me with a fresh example of exactly the non-engineering fluffy-headness that I enjoy making fun of.]

    Another one:
    Never use * in called queries, always use column names, because changes to the table may cause errors in your process.

    [James' Reply: Oh? What if I'm writing a quick throwaway tool and I don't care about maintainability? You are assuming a context without specifying it. As a careful professional, I feel I am not allowed to do that.]

    A third:
    Do not mix coding standards in a particular entity. Pick one standard, and stay consistent to enhance readability.

    [James' Reply: So, you're saying it is a universally bad practice to design my own coding standard based on studying others? What an odd and completely unsupportable claim!]

    Best Practices are something we try to attain, and the ideal, but sometimes we have to compromise for business reasons.

    [James' Reply: "Best practices" is a term used by marketers and other childish and wishful thinkers. I need to operate in the sober adult world of problem-solving and truth-telling. I am free to take and use the ideas you suggest. I think they are generally useful ideas. But why on Earth do you think I need the teddy-bear comfort of terms like "best practice" to do that?]

Leave a Reply

Comments are moderated. You might want to read my commenting policy before you make a comment...