Sometimes focusing on worst practices, rather than best practices, is the best way to tackle a problem. That might sound strange at first glance, but I take that approach more and more often in my consulting work. Here's an example of what I mean:

I perform a tuning audit and submit a draft of the final report. My customer requests that I include a section about best practices related to performance tuning and scalability. I respond with: I could include a section on best practices, but I'm not going to. I don't think focusing on best practices is a good use of our time. A comprehensive section about best practices would be at least 200 pages, possibly surpassing 500. For example, consider I/O performance—I could churn out 20 pages about RAID storage without even touching hardware or SQL Server best practices.

Best practices are wonderful, but lately I've come to realize that the best way to tackle a tuning problem is to focus strictly on eliminating the worst practices that you're currently engaged in. Is implementing a best practice the best thing to do if you're not going to get any immediate benefit? Maybe, but you shouldn't fret about it until all your worst practices have been kicked to the curb. Existence of worst practices in your application is what's causing your pain and suffering. Unless lack of adherence to a best practice is causing you pain, it's not a critical path item—unless it's likely to lead to pain in the future. So what about adhering to best practices to avoid problems in the future? That question is worth answering, so I'll cover that in a future commentary. In the meantime, adherence to my new philosophy might be good medicine for a larger percentage of SQL Server customers out there. Let me know what you think.