Ed Wilson: On understanding best practices

I was recently talking with someone on Twitter about my Microsoft PowerShell 2.0 Best Practices book, and the person stated that best practices were for noobs (beginners). The reason given was that beginners need guidance but experienced people have already created their own best practices by virtue of their application and experimentation. Hmm, I said…

This brings up the question as to what best practices really are. Regardless of the technology involved, best practices are intended to be a synthesis of the most appropriate manner of doing something, implementing something, or accomplishing something. While it is certainly understandable for people to seek out best practices, I am firmly convinced that in reality there are no best practices and that everything proposed as a best practice is first rooted in a set of preconceived notions, contrived environments, and artificial requirements. In short, best practices are theoretical guidance for a hypothetical situation to be implemented by mythical personnel. This should not be construed to limit their value, but it should serve as a caveat that to properly evaluate a best practice one must understand the scenario for which the best practice was designed.

As an example, consider a woodworking best practice governing the creation of joints for a box. To derive a recommendation for the type of joint to create for the box, you must first evaluate the type of wood being used for the box: Oak, Cherry, Walnut, Pine, Poplar, or simple plywood. Next you must determine how the box is to be used: to house jewelry, pencils, CD-ROMs, magazines, newspapers, firewood, tools, or ashes from a barbeque pit. After determining the material and the use of the box, you next must consider the budget for the box: in terms of resale, or simple terms of time. The best practice for the joint of a jewelry box made out of cherry that will be given as a gift to ones mother might require hand-cut dovetail joints. On the other hand, an ash box made out of plywood and sold at a flea market might dictate a simple butt joint with glue and crown staples fired from a pneumatic staple gun. Clearly the dovetail joint is the more aesthetically pleasing joint, and one that is synonymous with fine craftsmanship but the strength derived from the joint, and the time that is required to create the joint, may not be appropriate for plywood ash boxes—even there, however, I might conceive of a scenario where dovetails are appropriate if you are aiming for an upscale market.

The difference between noobs and experienced practitioners is not the adherence to best practices, but rather the insight as to when a best practice might apply. I once said in an interview that when it comes to scripting, I often do not follow my own best practices. This is not because I do not firmly believe in the application of the best practices that are set forth in the Microsoft Press book, but rather that when writing a quick script as a proof of concept I might not contain the logic in a function, I might not implement command-line arguments, I might not devise integrated help, I might not even add comments to the code—at least until I see for a fact that the concept will actually work! After I have proven that the concept works, I begin to rework the code, adding a modicum of this and a little bit of that, until the final product is in fact a script that fully adheres to my own best practices. In the intervening time, however, I am always at risk in incurring the penalty for ignoring the best practice – i.e., difficulty in reading the script, and increased complexity in troubleshooting the script. If I run into problems, I quickly begin to separate the code into functions so that I can more easily troubleshoot the script.