Best Practice

The term Best Practice flips the "yet another buzz word" bit of many of us literal-minded programmers.

"Best Practice" is industry jargon for "Better Practices" or My Practices. This page exists to:

Satisfy the Wiki Link Machine when someone writes "Best Practice".

Contrast BPs to those practices Pointy Haired Bosses come up with (Worst Practices?).

NOT define the Absolute Best and Absolute Worst. These definitions belong on the pages of the respective practices.

By contrast, a (full) Decent Practices page would illustrate the overlap between those practices that XP has adopted for its own and all the rest that are still progressive. Worshipping absolute comparators (like "Best") is, of course, a Worse Practice...

And let's not forget that the Best is the enemy of the Good Enough.

Here are some things teams do that don't suck.

Unit Tests (vs Big Bang Testing)

Pair Programming (vs Code Ownership or No Ownership Model)

You Arent Gonna Need It (vs Big Design Up Front)

Most practices have debatable relative merit, and not all conceivable bad practices are actually ... practiced.

Therefore my sample list is correct to list "Unit Tests" (do it or perish), and "Big Bang Testing" (the most subtle form of testing most Pointy Haired Bosses can conceive of).

Some of these things might not be obvious to a Pointy Haired Boss who grew up in, say, a hardware engineering environment. They don't recognize compiling as the assembly line, and think programmers are the assembly line and lines of code are the product. (They should read The Source Code Is The Design. And they should read it very carefully.) This might explain why for each of the practices there is a corresponding other practice that has appeared, at one time and in one form, in every programming shop that ever existed.

An excellent public resource for Best Practices is at: www.dir.state.tx.us

Small note: Many people (me included) happen to like Code Ownership, or rather, as Dave Smith amended it to, Code Stewardship. -- Alistair Cockburn

p.s. I find that most teams can't apply the "best practices". Most would be happy just with Decent Practices. But for the purpose of this page, they are perhaps the same.

Pair Programming and Code Ownership are not mutually exclusive. Pair Programming is better than Competitive Programming. Collective Code Ownership is better than individual Code Ownership. -- Don Wells

I like the concept of Best Practices. To make the name work for me, I mentally add "that I currently know of and use" to the end of the phrase, resulting in "the best practices that I currently know of and use".

Most people, me included, try to do the best job they can using the best techniques and tools they know of.

"The best practices that I currently know of and use" describes my personal best practices, which may be different from yours. But what of a group's practices? Can we work with the concept of "the best practices that we currently know of and use"?

For large sizes of "we", I have no idea how to do this. But for small sizes of "we", for example a development team, "we" can make a list. Making a list adds a second level of approximation and uncertainty, but we can keep improving the list until, in the spirit of Socrates, we know of no further improvements we can make to the list.

Thus we end up with "our best attempt at listing the best practices that we currently know of and use".

And as of today, that's the best description of Best Practices I can come up with.

"Best practices" is becoming a synonym for "the way I do it". It is used as a marketing term (see also Proof By Vigorous Hand Waving), and as an argument for the status quo.

My friends will testify that the phrase "Best Practice" is enough to get me on my soapbox...

As far as I can tell, Best Practice is a grossly misused term. It is often used as a short cut instead of thinking for oneself. If a practice is good, it should be possible to justify it in its own terms; and if not, calling it Best Practice will not improve it. Whether a practice is good for me or not depends on what I am trying to do with it. Just because some others in a similar (but not identical) industry do something and have judged it to be (or call it) best practice does not automatically guarantee that it will be good for me. Small differences in situation can result in a large difference in effect. I therefore look very suspiciously on those who tell me to do something because it is Best Practice.

A specific example: I work for a research organisation and write software. The organisation is ISO 9000 certified, and we therefore have procedures. But because some of the software we write is for customers, all our software must be written to absurdly high "standards". It is exhausting to try to fight the battles, so now I and most of my colleagues pay lip-service to the procedures. I hope the auditors don't find out... -- Anonymous for obvious reasons :-(

''This behaviour is not mandated by ISO9000. Find some new auditors.

Hmmm. It looks like using government and other local folk traditions to enforce someone's opinion of "Best Practice" might just not be Best Practice! Who would have thought it? -- Phl Ip

The opening statement brings up a point. The term Best Practice implies consensus. The fact that, here on this board full of programmers there is considerable overlap between the pages devoted to the absolute Worst Practices and those devoted to the absolute Best Practices tends to make you lose hope of coming up with consensus "real soon now".

It is not uncommon for organizations undertaking an activity to survey their own industry to find out how others do the same activity. The person or team conducting the investigation would likely judge which practices they encounter are best, usually by criteria established in advance. With current best practices in hand, the organization is still free to innovate should they feel the best practices of their peers insufficient to their own goals.

pay lip-service to the [ISO-9000] procedures

Many software developers use a step-by-step process to model software development, for the purposes of ISO9000 or CMM (i.e. they come up with a flowchart). My personal experience is that a step-by-step process makes a poor model for software development. I.e. not a good medium - like using clay to model a Mozart symphony.

Is there a better medium? For me, the best way (so far) to model software development is a fixed-size set of rules (e.g. Extreme Programming Practices). Can I prove this is the best way to model software development? No. Can I even prove this is the best way for me to model software development? No. I think it is the best way, of the options I currently know about.

No. Patterns may be best practices, but best practices don't have to be patterns. Patterns have a form that best practices don't have to have.

I agree with the above comments about Best Practice being a misused term and a synonym for the status quo (also a synonym for the rationale to move to a new status quo - see Satir Change Model). The one thing that all Best Practices ignore is Context. What works for your environment doesn't work for mine, and vice versa. -- Phil Stubbington

Quote from the Lisp world:

"The demise of Lisp at JPL is a tragedy. The language is particularly well suited for the kind of software development that is often done here: one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules. The efficacy of the language in that kind of environment is amply documented by a long record of unmatched technical achievements.

"The situation is particularly ironic because the argument that has been advanced for discarding Lisp in favor of C++ (and now for Java) is that JPL should use "industry best practice." The problem with this argument is twofold: first, we're confusing best practice with standard practice. The two are not the same. And second, we're assuming that best (or even standard) practice is an invariant with respect to the task, that the best way to write a word processor is also the best way to write a spacecacraft control system. It isn't."

(Erann Gat)

Emphasis added by Doug Merritt.

Best Practice is when you follow a vendor's published guidelines because you don't have a $billion interop lab and several weeks or months of time to dedicate to figure out the "best" way yourself.

Best Practice is the justification you use to insist on following these guidelines to counter Proof By Vigorous Hand Waving.

The notion of Best Practices (more accurately, Very Good Practices, as seldom if ever will any practice be shown to be better than all others) is a valuable one; unfortunately the term has been sufficiently abused to be at Buzz Word status.

The problem is, of course, that anyone can call anything a Best Practice (complete with marketing literature to "prove" the claim), without doing the research to demonstrate it. There isn't any easy way to weed out the good practices from the bad ones. And by calling something a Best Practice, often times a decision which is arbitrary and/or political in nature will gain the appearance of being a technically sound judgement.

To help weed out Bad Best Practices, a few suggestions:

A Best Practice should have at least some research behind it; research conducted by vendors, by industry trade rags (who are in the business of Selling Eyeballs), or anyone else with an obvious conflict of interest should be considered suspect.

A Best Practice should actually be practiced somewhere, with demonstrable (and successful) results. To label as Best Practice something which is experimental is patently absurd.

Distinguish Standard Practice and Best Practice.

Additional Point

Sometimes we may miss the point that Best Practices are not always and only those which are invoked and mandated, for they can also include the best of what an individual can do and has done. It also including those practices which one has found to prove their worth by the passing the test of It Works in many different situations and settings and that one also knows why It Works. It can be said that a Best Practice is the careful application of means and methods which bring about a successful result. Best Practices should never be employed as a method of shedding personal responsibility for the product upon which we labor. -- Donald Noyes

The opposite of a Best Practice is a Code Smell.

See also www.javapractices.com - concise presentations of Java practices, tasks, and designs, illustrated with syntax-highlighted code examples.

See Also: Benefits Are Subjective, Database Best Practices, Popular Way Of Doing Things, Code Smell, www.fairlygoodpractices.com

Category Jargon

See original on c2.com