Best practices, and other fine myths

It’s a rare conference that doesn’t include at least one (dozen) “best practice” sessions. A search on 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.


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.

4 Responses to “Best practices, and other fine myths”

  1. Mike Gale Says:

    For somebody who does the same thing again and again “rather good practice” is attainable. For the person who does different jobs and seldom revisits there’s a huge problem in:
    1) Remembering how it works, grokking existing code again…
    2) Not wasting time
    3) Still having robust code.

    I guess we need tools to get us into a good mindsets to tame this feast of technology!

  2. Matt Says:

    Very good. It’s important for people to think about basics like this.

  3. joeycalisay Says:

    excellent point sir!

  4. Craig Says:

    As others have pointed out, an excellent point. I just wanted to add that this is why I’m an admirer of design patterns (specifically the original GoF book). All patterns in that book are accompanied by an explanation of when and where it should be applied (including actual examples). As you point out, general recommendations or practices are useless without context: I suppose that’s why one of the most common answers to technical questions is “it depends”! 🙂

Leave a Reply

Comments are moderated - allow 24-48 hours for your comment to appear.