Best Practice

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

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

Satisfy the Wiki Link Machine when someone writes "BestPractice".
Contrast BPs to those practices PointyHairedBosses come up with (WorstPractices?).
NOT define the Absolute Best and Absolute Worst. These definitions belong on the pages of the respective practices.

By contrast, a (full) DecentPractices 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 GoodEnough.

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

UnitTests (vs BigBangTesting)
PairProgramming (vs CodeOwnership or NoOwnershipModel?)
YouArentGonnaNeedIt (vs BigDesignUpFront)

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

Therefore my sample list is correct to list "UnitTests" (do it or perish), and "BigBangTesting" (the most subtle form of testing most PointyHairedBosses can conceive of).

Some of these things might not be obvious to a PointyHairedBoss 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 TheSourceCodeIsTheDesign. 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: http://www.dir.state.tx.us/eod/qa/bestprac.htm

Small note: Many people (me included) happen to like CodeOwnership, or rather, as DaveSmith amended it to, CodeStewardship. -- AlistairCockburn

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

PairProgramming and CodeOwnership are not mutually exclusive. PairProgramming is better than CompetitiveProgramming. CollectiveCodeOwnership is better than individual CodeOwnership. -- DonWells

I like the concept of BestPractices. 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 ProofByVigorousHandWaving?), and as an argument for the status quo.

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

<rant>

As far as I can tell, BestPractice 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 BestPractice 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 BestPractice.

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 :-(

</rant>

''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 BestPractice! Who would have thought it? -- PhlIp

The opening statement brings up a point. The term BestPractice implies consensus. The fact that, here on this board full of programmers there is considerable overlap between the pages devoted to the absolute WorstPractices and those devoted to the absolute BestPractices 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. ExtremeProgrammingPractices). 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.

A BestPractice is another name for a Pattern A WorstPractice? is another name for an AntiPattern

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 BestPractice 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 SatirChangeModel). The one thing that all BestPractices ignore is Context. What works for your environment doesn't work for mine, and vice versa. -- PhilStubbington

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

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

BestPractice is the justification you use to insist on following these guidelines to counter ProofByVigorousHandWaving?.

The notion of BestPractices (more accurately, VeryGoodPractice?s, 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 BuzzWord status.

The problem is, of course, that anyone can call anything a BestPractice (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 BestPractice, 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 BadBestPractice?s, a few suggestions:

A BestPractice should have at least some research behind it; research conducted by vendors, by industry trade rags (who are in the business of SellingEyeballs?), or anyone else with an obvious conflict of interest should be considered suspect.
A BestPractice should actually be practiced somewhere, with demonstrable (and successful) results. To label as BestPractice something which is experimental is patently absurd.
Distinguish StandardPractice? and BestPractice.

Additional Point

Sometimes we may miss the point that BestPractices 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 ItWorks in many different situations and settings and that one also knows why ItWorks. It can be said that a BestPractice is the careful application of means and methods which bring about a successful result. BestPractices should never be employed as a method of shedding personal responsibility for the product upon which we labor. -- DonaldNoyes

The opposite of a BestPractice is a CodeSmell.

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

See Also: BenefitsAreSubjective, DatabaseBestPractices, PopularWayOfDoingThings?, CodeSmell, http://www.fairlygoodpractices.com/

CategoryJargon