“Best” Practices Ain’t...
First published April 17, 2017
For the first 20 years of my career I was obsessed with the set of rules that would guarantee success. What I was really seeking was absolution. I did The Rulez right, it’s not my fault. Doesn’t work like that.
...usually. Mea culpa: I once published a book with “Best Practice” in the title. Most uses of the phrase, though, are distracting at best, confusing and misleading at worst. Given the increasing use of the phrase (at one employer, 19 Slack channels include it in their title, more data needed), here’s some perspective for “best practice”.
Quick thank you to my first sponsor, Tuple
Tuple—Fun Collaboration Now
Collaboration enhances focus. But what if you get distracted on the way to collaborating? Tuple's 2 engineering pillars are:
Make it easy to start a session
Make pairing fun
Invite collaboration with 2 clicks with Tuple. Use code KB1 to get 33% off your team's first year.
Use
To understand how “best practice” is used productively, we need to step back and realize that all problem domains are not alike (analysis stolen from Cynefin):
Chaotic problems have no clear link between action and effect. Best practices are expected to have predictable effects, so they fail when applied to chaotic problems. Better to act first and analyze later. With a chaotic problem, almost any action will produce useful feedback.
Complex problems display a connection between action and effect, but only in retrospect. Applying a best practice will not get you what you expect. Instead, your best strategy is to invent an action based on first principles (like “move fast and break things” or “make decisions reversible”), and observe the results.
Complicated problems have a, well, complicated connection between action and effect, but at least they are predictable. A best practice is not effective, but choosing among a pallette of known-good practices is.
Simple problems have a clear, linear connection between action and effect. When solving simple problems, effort used to invent or choose between actions is a waste of time. Applying the best practice is efficient.
Misuse
Having been through a few “best practice” wars, I have seen two dysfunctions with the phrase. Sometimes advice givers use it to mask lack of confidence. “Do what I say because it is a best practice.” Sometimes advice takers use it to try to duck responsibility. “But I was using a best practice.” Neither is consistent with effective development.
Conclusion
When you have a simple problem, by all means seek out and refine the best practice. For problems where the connection between action and effect are still coming into focus, derive actions from first principles or choose from among known-goods. But don’t call it “best” practice if it ain’t.
I very much dislike the term. My objection to it has always been, "How extensive was your evaluation of practices that led you to call this one best?" Because usually the answer is, "Not very". At best it was, "Because <legitRecognizedAuthorityOnTheSubject> said so." But often it's, "Because I think so," a purely narcissistic response. It usually has the empty validity of, "Many people say..." Who? What people?
So I much prefer to say "recommended practices," with some backup to the recommendations. If it's just me, I'll say, "My preferred practice."
I was chatting with one of my kids this morning about the word "should". And since he's done some coding, I was able to use the analogy that sometimes "should" is a handy abbreviation, but often it can be an obscuring abstraction. In code, when an abstraction seems to be hiding information in an unhelpful way, I can try to inline it. In collaboration, I've also increasingly tried to "inline" terms like "should" or "best practice". "When you say that, what do you mean?"