Everyonce in a while someone pulls out the rhetorical hammer and calls something a “best practice”. In german I call this a Totschlagargument, the best translation I could find seems to be thought-terminating cliché. My favorite political example from that wikipedia page:
“…or the terrorists win.”
Anyway, whenever someone pulled best practices out of his sleeve, I want to tell them “There are no best practices!”. But lacking good arguments to back me up in a discussion, I usually wouldn’t. Until now!
This article simply called No Best Practices does a good job of explaining why the idea of a best practice is wrong on several levels. For a start, practices depend on context:
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.
The author, James Bach, later suggests various alternatives:
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.”
He even covers various responses to his arguments and his replies to them:
“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.
There is more good stuff in the comments, highlighting Jame’s focus on testing:
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.]
My conclusion: Whenever you encouter a “best practice”, try to take it apart. What’s the context? Is it really a practice, oder just a goal? Is there anything specific of value, or just generic and ambigious rhetoric bubble?
This seems like an argument that boils down to semantics and context. “Test early, test often” is, in the context of the discussion, about software development, not making a sandwich. If you worked in a restaurant kitchen then the “Test early, test often” mantra is not applicable, but the “Wash your hands after going to the bathroom” is.
I agree with what James is saying, but his counter-arguments are assuming that there is no context. He is, after all, a software tester consultant. Does he really think that sandwich makers are reading and commenting on his blog???
@tatlar: The sandwich argument illustrates the lack-of-context argument well, nothing more. Touting something as a “best practice” and assuming “software development” as the only context isn’t nearly specific enough. I’m sure there are enough contexts within software development where “test early, test often” isn’t a good advice.
But we must have best practices, or the terrorists win.