Who Decides What Is A "Best Practice"?
- select the contributor at the end of the page -
Nick Malik posted an excellent blog post as a result of viewing several sessions during the Open Group Conference that had him ask how we decide what constitutes a "Best" practice. In the blog post he describes the difference between agreement on the suitability of a practice and the labeling of that agreement as "Best".That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.” -- Nick Malik's Blog
The problem as I see it is context. In order to define a practice as best, you have to generalize the various constraints that point you in one direction or another. For example it could be said that using a Provider pattern for an Authentication model in an application is a "best" practice (as used by ASP.NET, SharePoint, etc.). In that pattern each provider is generally defined in a separate assembly and loaded dynamically via dependency injection or good ol' app.config. But what if you have to pay a real world fee for each DLL shipped with your application for it to be tested by an independent laboratory for regulatory compliance, as is often the case in financial, (casino) gaming, and other highly regulated areas? Does that mean the practice of breaking up code into assemblies is no longer a "Best" practice? The previously undefined context can negate a practice's "Best" label.
Of course, any Enterprise Architect that answers every conference question with "It Depends" probably doesn't get called back to speak again very often. But the suitability of any practice not only depends on the constraints and acceptable outcomes but is in fact defined by them. Nick touches on this in his recommendations for how to determine if a practice is indeed deserving of the label of "Best".
- Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
- A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
- Some analysis to show that it meets other criteria like broad applicability and simplicity, and
- We should demonstrate the ability for that practice to be understood and performed by people who are currently
What is considered "best" practice also changes with time and opinion. I read a book from the early days of .NET written by a Microsoft Architect that stated that a best practice for web services was to return the System.Data.DataSet object, which is extremely .NET specific and not cross platform agnostic (i.e. a really bad idea). We've seen others come and go from using Try/Catch in every method block to the venerable Visual Basic OnError Goto abused for branching logic.
So what practices do you see that still bear the label of "Best" that need to be reconsidered? What are your recommendations for how to decide and describe what are and are not best practices?
