Are “Best Practices” Best?

The fact that an opinion has been widely held is no evidence that it is not utterly absurd; indeed in view of the silliness of the majority of mankind, a widespread belief is more often likely to be foolish than sensible.          — Bertrand Russell

That’s the nut of what I wanted to say, but I’ll belabor the point a little more.

Look in any corner of the software industry and you’ll find abjurations to use copious listings of “best practices”. Development processes, coding paradigms, language idioms, team management — “best practices” are everywhere. You may have noticed the quotation marks. Although really, they should be just around “best”, but you so rarely hear the words separately these days…

As an industry, software development is so young that it’s not at all surprising — and indeed it is very helpful — that so many people are willing to share lessons learned to advance the state of the field. This is wonderful, and one of the best things we’ve seen from this impulse is the rising importance of software patterns of various types; design, implementation, anti-patterns, etc.

Early on, one of the rules of software patterns  was that you needed to cite where the pattern you were documenting was being used in actual practice — that is, in a system in active use in some industry or setting. Not only that, but you needed to list at least 3 to 5 such uses or you couldn’t really consider what you were documenting a true “pattern”. Unfortunately, I fear this rule has kind of fallen by the wayside over time.

Which leads us back to the evil twin of software patterns: software best practices.

The phrase “best practice” leads one to believe that the practice has somehow or other been shown to be “best” in at least some aspect or interpretation. This is a bold assertion: even patterns don’t make this kind of claim. In fact, the patterns world tends to make lots of useful caveats that constrain the use of the pattern to particular contexts in the presence of particular forces. Not so with best practices.

A best practice is typically created simply by someone asserting it as a best practice. In the worst case, this is done simultaneous with the initial release of the technology — i.e. along with a release of a software framework comes a copious list of best practices. How can the “best” be known in any meaningful way with something so new? In more typical case, best practices are simply asserted with conviction, but without citation of why it is “best” or what alternatives were considered.

I think too often people confuse the word “best” with “common”. Many best practices are indeed very common, and maybe even with good reason. But unless you understand why a practice is “best”, you cannot possibly use it appropriatelyMaybe it’s a bit like IBM in the distant past: no-one ever got fired for buying IBM. Similarly, no one ever got in trouble for using  a best practice. Probably true.

But the danger is that more effective alternatives will be overlooked in blind obeisance to best practices that were arbitrarily determined and never in any way supported. If there are reasons for a best practice you use, you should know them and be able to justify (or at least convincingly argue) that the practice is “best”. If a “best practice” has no particular justification, then it is simply an opinion and should be evaluated as such. And if you are just parroting something you saw once on a web-site somewhere, you shouldn’t call it “best”.

In a design discussion, I find it depressing and disturbing when a component or element of the design is justified solely by saying it is a “best practice”. This is nonsense. If it is truly a best practice there are reasons why it is a best practice, and those reasons support its use in the design. The fact that it is a “best practice” can be used as a discussion shortcut (not unlike using common pattern terminology) but far too often it is used as a justification in and of itself.

I’m not at all against the idea of best practices, but I think we, as an industry, need to be more judicious in how we bandy about words like “best”. Requiring even just a little bit of rigor in what we label “best” would be a useful and welcome change.


About jeffkotula

Software engineer, musician, and so on...
This entry was posted in Coding, Process, Software and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s