It’s a rare conference that doesn’t include at least one (dozen) “best practice” sessions. A search on Amazon.com found 166 computer books with “best practices” in the title, an astonishing 2500 that have “best practices” somewhere in the description.

What are best practices? When you come right down to it – they are for most people a shortcut to expertise. The knowledge base required to be a professional software developer today is huge. To be a good one, even greater. Learning programming and a language or three is trivial, and just the beginning. There are also the tools, for both development and management. The platform you’re coding to (.NET framework, Win32 API, etc.). The services you’re using (web servers, databases, etc.). Each of these has to be configured. Most have their own languages as well (I just finished a project that required me to simultaneously program in VB .NET, C#, Regex, Javascript and SQL).

And the knowledge base is a moving target – every year or two it changes, grows and becomes more complex (sure .NET 2.0 twice as good as 1.1 – there’s twice as much to love, and learn.)

We can’t know it all. We can, if we’re very lucky, learn those parts of it we need to solve the problems at hand. If only an expert could come along for each of these technologies and teach us just what we need to know – being sure to include those “gotchas” learned through harsh experience. In other words – “best practices.”

Sounds good, right?

The problem is, those best practices can come and bite you. Because the phrase “best practices” is misleading. It’s incomplete.

The correct phrase is: “Best practices for solving X class of problem”

“Best practices” are always associated with a particular set of scenarios. And if you don’t know those scenarios, you can be in deep trouble. Because best practices for one scenario can quickly become worse practices for another.

Case in point:

Imagine if you will, an ASP .NET web application. Everybody knows that it’s a good thing to reduce round-trips to the server. Most ASP .NET “best practices” emphasize techniques to reduce round-trips and reduce network traffic. Like spitting out client side script for validation and to handle some of the user interaction. Like turning off viewstate where possible.

And you know what, those are all good recommendations.

Unless…

Imagine this ASP .NET application has section, say maybe half the site, that is very rarely used. Maybe it’s for administrators only. Or maybe it’s used rarely, say to view 1099 forms at the end of the year.

Coding a web application that makes heavy use of client side scripting is hard. It’s hard to develop. It’s harder to debug. It’s harder to maintain. It costs more. It turns out that for low traffic portions of a site, those performance “best practices” are actually worse practices. They cost a lot, and no one may ever notice the benefit.

I’ve seen projects like that – where developers follow the “best practices” recommended by Microsoft or experts, only to come up ultimately with brilliant implementations of flawed architectures. Best practices are not a substitute for understanding the fundamentals.

So next time you attend a talk that promises to teach you best practices, or read a book with that in the title, be sure to take a minute and ask “best practices for what kind of problem?” Because if it’s not your problem, chances are you’re about to be led astray.