Not sure I totally agree with you here. You're watering down things quite a bit. For example, I feel pretty comfortable stating that it's 'best practice' to wear a helmet while riding a bike.  Is it the only way? Nah. Are you likely to get in an accident when riding a bike? Nah. But when you DO get into an accident, the stakes are simply too high not to wear a $20 helmet and prevent thousands of dollars in surgery and physical therapy when you get brain damage.

Likewise, what I usually call Best Practices are not the only way to do it. It's not always the fastest, etc. But when the moment of truth comes, I have lots of empirical evidence that shows that these techniques have been the only ones that remained standing when the dust settled.  And I have a number of noted industry experts with many successes under their belts ahead of me who have found this out also (and clued me in).

With bicycle accidents, there's statistical proof, not to mention common sense, that proves that wearing a helmet is a 'best practice'. Unfortunately with software, no one has yet devised a good system for measuring the success of 'best practices' or, consequently, the failure of NOT using them, so that allows some subjectivity which is perhaps what you're lamenting.

The real answer here is, we need to prove with real evidence, not just empirical evidence, that these practices really are 'best'.

The way I define Best Practice, I often times think its better to be renamed as "Proven Practice".  This is a method/pattern/technique that has been used in other places successfully.  So if you're looking for a way to do "X", instead of re-inventing the wheel, you can re-use this practice.

@Chad

"But when the moment of truth comes, I have lots of empirical evidence that shows that these techniques have been the only ones that remained standing when the dust settled."

We've had this conversation before, and I don't believe you have this evidence.  You have a lot of anecdotal evidence (personally experienced and otherwise), but there isn't anything concrete out there that shows this.

I agree, we need to get away from "Best practice" as a term.  I prefer "generally accepted pactice", which gets away from superlatives and the implied "cannot be better".

Both Chad and Nick make excellent counter points, so my goal is not to sound redundant.  With that here are my 2 cents worth:

To ME, best practices is about leveraging the “greater” knowledge/experience of a broader community… the community of developers and software design when it comes to patterns, the community of those dictating and thinking about process when following Agile as a best practice, to address both of your points.

It is all about learning as a community.  I don't know if I entirely agree with the need to "measure" with statistics or other means, as a criteria to define a Best Practice.  It certainly helps to make the point, but some benefits of certain Best Practices are not so black and white.

Granted statements like “it is THE definitive way to do this" are going to be easy targets to kick down one thing or not holds true… one can certainly choose to be *that* stubborn and do as one pleases without choosing to leverage the progress attained by other’s trial and error.

Pingback from  Best Practices Are Crap « Pistalwhipped!

There is no one Best Practice, there are many best practices ...  whichever methodology or techniques you use, you should be doing them to industry best practice ... that means, not being sloppy, not cutting corners, and geneally being professional.

@Derik:

Note that they're called 'best' practices, that doesn't mean that other practices are 'bad'. Shades of gray/levels of success is at play here.

To further clarify my point: I know more about what DOESN'T work than what does. I know a few things that do work in most cases, but I know a TON of things that DO NOT work in any case. I define 'work' as satisfying functional requirements without having to change much in the future as the software changes and adapts to new requirements. Properly decoupled software involves components that may not ever change over the life of the product because they do what they're supposed to do and are isolated enough from the rest of the system that other, major changes do not affect this component.

Most people, from my experience, define 'work' as "I can drag this component onto my form and wire up the on-click event and then ship the product".  Which is great, until 3 weeks later when new requirements come down the pipe and you have to make a bunch of changes and thrash the system to accommodate them because you didn't decouple your design.  To me, that's not 'works'.  You traded huge technical debt for a quick victory and, in almost every case, that's irresponsible and unprofessional. The only time this is acceptable is when you have made the stakeholders fully aware that this quick win will cost them in spades in the not-so-distant future and they make the conscious, full-knowledge decision to incur that debt because some market force is requiring them to do so.

However, from what I have seen and heard from most people, rarely are the stakeholders made properly aware of this trade-off and are blindsided by the bad news when they come later and wish to add a new feature.

If you find that your business is frequently rewriting software and bringing in new teams to do things over and over, you know what I'm talking about. This is, most certainly, NOT a good thing and NOT a best practice.

Pingback from  Arjan`s World    » LINKBLOG for May 30, 2008

I would agree with the author, and make the case that the selection of the appropriate practice or tool should be dependent on the specific context in which it is being considered. Too often in this field we select a practice solely on the basis that a supposedly reputable source defines it as "best" (an appeal to authority). I take issue with any recommendation for a particular practice or tool that is made without consideration of the specific context to which it should be applied, and unfortunately I think this is done entirely too frequently in this industry. We're still in the dark ages of software development, and whatever practices we define as "best" today will probably seem pretty naive to future generations of software developers.

I would recommend that as software developers we do our best to consider the context of our problem, evaluate competing practices and tools that are potentially appropriate to the problem we're solving, and after considering the benefits and drawbacks of each, select one. Someone else's "best" practice is just a another potential option that may or may not be appropriate in your context.

Pingback from  Dew Drop - May 31, 2008 | Alvin Ashcraft's Morning Dew

The way I define a best practice, out here in my cube in the middle of corporate America? Easiest question ever.  Anything that came from a demo from Microsoft.

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #105

Pingback from  What the &@$#* is a ‘Best Practice’ anyway?

Pingback from  Best Practices Are Crap « Code: Impossible