In my last blog post, I discussed a CSS trick I recently discovered. That post spawned a lot of comments, and at one point in the discussion I stated that I felt that just because a technique is popular and has been put forward by one or more resources as best practice, that it doesn't necessarily make that technique better practice than a new practice I (or any developer really) might come up with. The question was asked, "where do best practices come from?"

But who develops these "best practices"? It must be some mystical group of people who magically know the best way to do something. Not the people in the field who actually do the work, right? ...How does one join this group of highly advanced people that are so much more knowing than us mere mortals about best practices?

Before I address this question, I'd like to give a little history about myself.  In the mid-90's, I showed dogs in the sport of Obedience.  At the time, the "best practice" was that you didn't use food to train dogs, because the dog should to it "because you said so."  I was an early adopter of clicker training, a technique that uses food as a reinforcer for desired behavior, despite enormous pressure from the dog training community to continue jerking my dogs around by the neck like everyone else was doing at the time.  Today, clicker training is widely accepted as good practice among trainers of many species.  I have a milk goat because I believe that the widely held "best practice" of pasteurizing and homogenizing milk results in a food product that is toxic.  So I start from the point of view that my own informed opinion about what is best practice is as good as anyone's.

And I think any developer, consumer, or citizen has the right to put in the research time to study what current practices are and the reasons for them and put forward alternatives that can be considered for adoption as best practices.  Just to be clear, my last post was not written with the intention that the technique be considered as best practice.  It was written to share a technique that was more in line with what I consider to be the underlying principles of good CSS practice than any that I had previously used. 

I think this idea is at the heart of my disagreement that the alternative technique that was put forward, one that requires an additional <div> tag, was better practice than the one I had posted.  Whenever I am comparing two techniques in a language to see which is best practice, I ask myself not, "Which technique is more widely used/popular/endorsed by a reputable company with an interest in the language in question," but instead, "Is this technique more in line with what I understand to be the underlying definition of what is or is not best practice in this language?"  For me, the underlying definition of best practice in CSS is that it keeps the mark up separate from the presentation.  That is the ideal.  So a technique that supports that separation is going to be better practice than one that requires the markup to change in order for the design to work.  This is also a call any developer is qualified to make—it is much easier to determine if you have to add markup to make a technique to work than it is to determine how "popular" a technique is or whether the specific Apple employee who wrote an article about CSS best practice thoroughly understood the techniques he was describing on the day he wrote the article.

To give you a more concrete example, I am one of the moderators of the Adobe Community Help (Livedocs) for Flex.  In that capacity, I see many instances where a member of the developer community will write in with a correction to the official documentation. Even documentation written by the company responsible for the product is not infallible.  My hat is off to Adobe for recognizing that even with all the effort that they put into making the documentation as accurate as possible, it is still just the best understanding of the employee who documented the topic on the day.  Livedocs provide an effective way for the community to improve on that understanding as the product is out in the field, even if the documentation team has moved on to another project (like the next version).

Sometimes the idea of what is good practice is not so cut and dried as "does it keep the mark up separate from presentation," and a good example of this is the debate over Cairngorm, Adobe's Framework to implement the Model-View-Controller design pattern in the Flex development platform. Clearly, Adobe feels it is good practice, or they wouldn't recommend it, but some developers believe it is actually bad practice.  I think to a certain extent that the difference between whether you see it as good or bad practice is determined by the size of the project and the team, but I also believe that part of the difference in perspective is whether you think just MVC is important, or if you focus on the underlying reason MVC is seen as good practice—loose coupling.  I think if you are more focused on loose coupling than MVC, you are less likely to consider Cairngorm as good practice.  But you still might wind up using it in a large team situation if more developers are available that are familiar with Cairngorm than other frameworks.

To answer the question of who "magically" knows the best way to do things, no one.  But the steps to join the group that does are simple, if not easy:

1. Put in the research time to figure out what "defines" good practice in the language
2. Understand existing techniques well enough to synthesize your own
3. Put forward the techniques in a forum where they can be debated, hopefully with leading experts
4. Be prepared to back up your new techniques with arguments that show you understand good practices in general
5. If you get shot down or convinced your technique isn't so hot after all, go back to step 2

Read more from Amy Blankenship.