I read James Bach's essay entitled No Best Practices today and I loved it. I have always abhorred the "best practices" meme, which I regard as a substitute for thinking. At my last job, "best practices" were the Holy Grail or Fountain of Youth that we were forever seeking. At nearly every design or development meeting, someone would bring up that we needed to "find the best practices and stick to that" for some project. As if programming were a matter of upfront research and rote coding!
The concept of "best practices" might sound good on the surface. Who wouldn't want their development efforts informed by the best advice? These aren't the "adequate practices" after all. These are the best of the best of the best. Sir. Ostensibly, they represent the received wisdom of the software engineering profession.
Except, of course, that they don't. Bach makes the point that there's no such widespread accord. Further, such consensus wouldn't be particularly useful even if it existed. While every general problem in software engineering has been developed, every program has specific applications of that problem that are unique. Design patterns are great, but they're understandably vague and require a programmer to implement. Code reuse within a program is admirable, as are frameworks and libraries. There isn't a framework or library out there, however, that doesn't require a programmer to take the functionality in the library and craft a program that uses it.
"Best practices" persist because the worst kind of managers don't trust their programmers. They want the reassurance that their employees are following someone else's advice or toeing some preset line. For some reason, they have a sort of departmental low self-esteem that makes those on the outside seem like geniuses and those on the inside incompetent. Perhaps that's too strong of a word. It's more of a lack of confidence than an explicit assessment of ability. Managers of this sort typically fall back on big-name, expensive consultants to allay their irrational fears. Never mind that the consultants aren't able to comprehend the minute ins and outs of the business in the short amount of time that they interact with it. Never mind that the quality of consultants is completely uneven. So long as they're willing to sling their particular brand of hash as "best practices", they'll find willing managers to support them.
The thing that pisses me off most about the "best practices" drivel is that they steamroll right over the true "best practice" in programming: use the right tool for the job. If your project requires substantial abstraction and multiple layers, go for it. If it doesn't, do the simplest thing that works. Overdesign is a code smell that begs for refactoring, though it is usually the hardest thing to refactor. It's so much easier to repeat the hell out of yourself and then refactor the repetition out. Easy and simple aren't sexy, though, so you constantly encounter programmers who want to make things complicated.
And that's the really unfortunate part: the complicated, overdesigned solution is often more attractive to the "best practices" crowd because they're awed by things that they don't understand. If they can understand it, they reason, then it must be simpleminded. Why roll your own basic CMS when you can use a million dollar system like Vignette that does everything for everybody? Vignette is a beast whereas straightforward server-side creation of HTML is simple. Clearly, Vignette is more powerful—never mind that there's no demonstrable need for its power.
Context is key: do the simplest thing that works using the right tool for the job. There is no be-all, end-all solution. It's a chimera. "Best practices" at their least offensive are nothing more than design patterns and helpful advice. Call them that. At their worst, though, they're a snake oil that has a stultifying effect on programmer initiative. In the wrong hands, they can be a club to be wielded whenever a programmer wants to think different or just get things done.
If you're a member of the "best practices" crowd, do some introspection and take a really good, hard look at your expectations surrounding their use and whether they've actually produced anything of significance when forced onto programmers. I think that you'll find that they're not all they're cracked up to be. And if you encounter a sales demo or a consultant who piles on with the jargon and the "best practices" talk, know that he's inadvertently alerted you to his true nature. Usually, you don't get that lucky until after the sale.
[UPDATE (4/8/2006): Jeff Atwood shares my disdain.]