Home >
I hear a lot of talk about "best practices" these days, and I'm sure you do too. As design has become a more visibly important differentiator for web development professionals and companies, understanding the "best way" to accomplish any given task has been a big deal, leading to a plethora of blogs, conferences, podcasts, etc. on the topic. How can I communicate that there's more information to fill out? How can I make my form most intuitive? How can I present an intuitive interaction? These are the types of questions "best practices" are called upon to answer.
Wikipedia currently defines best practices as:
"Best practice is an idea that asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a desired outcome can be delivered with fewer problems and unforeseen complications."
Let's pause on "practices" for a second and talk about "principles." Here's the difference between the two: a practice directs specific action - something like, "implement an analytics package to track user trends." A principle is something more abstract that speaks to the ultimate goal - "find out how people are using your site", to stick with our analytics example. Principles are general, abstract, and timeless; practices are specific, focused, and dated.
The problem with "best practices" in this industry is that the best implementation of any good principle changes before it can be standardized. Put another way, by the time you've heard of a best practice, there's a good chance it's not the best anymore.
Case in point: one standard, rote, run-of-the-mill "best practices" article from November of 2008 says, "your phone number should be prominent and located at top of page in large type." The principle behind this "best practice" would be something like, "make sure a method of contact is easily accessible." By removing the specifics, we open the realm for all sorts of implementations: sometimes email might be more appropriate, or a link to your customer service page (user voice or get satisfaction have done a great job of providing this as a service), or even something else.
The "something else" is amazingly important for one big reason: innovation. By ignoring best practices and focusing on the "best principles" behind them, we leave the matter open for new interpretation. Rather than providing your phone number, why not embed a widget powered by Ribbit that allows your users to call directly from the web page? Why not embed a link to your skype name?
"Best principles" are timeless truths about the way people think and interact with information. Best practices are based in the here and now, tied to technology, trends, fashion, and common implementation. Some of the most interesting web-sites at any given time are those who quite purposefully break with "best practices" and try something new, often inventing tomorrow's "best practice" in the process.
Focusing on best practices encourages stagnation - the repetitious implementation of old ideas rather than the creative development of new ones. In the analog world that kind of thing can get you by, as innovation in technology and metaphors can take a few years to really move things, but here in the wild digital web it only ensures you'll be left behind.
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Great post RJ. Probably the best article I have seen on InsideRIA to date.
You captured something I've felt nagging in my mind for a while now and hope to write about in the future, which is that we too often let these "best practices" constrict our thinking. On more than one occasion I have caught myself trying to shoehorn a solution into a specific framework or design pattern and I end up stuck and spinning my wheels. Once I realize that, take a step back and simply focus on the problem in front of me, I find it's much easier to devise the proper solution.
Reducing a problem to its most basic components and laying out equally basic goals for solving it is essential, and I think you've articulated that extremely well.
Some great points here, RJ. Thanks for starting the discussion.
The problem with "Best Practices" is very similar to the problem with Design Patterns - people take them (or write about them) too literally. Best practices should describe a common approach to solving a problem - but not the actual SOLUTION to the problem. In the example you mention, a best practice would be "make sure that one more means of contacting you are prominently featured on your page", as opposed to specifically suggesting the phone number. Any recommendation this specific is bound to be brittle.
I think you're unnecessarily bashing "Best Practices" here.
Best practices arise when number of people come across a commonly occurring problem and determine propose the best possible solution. Its never mandatory that this practice be used, but in many cases those who paved the way have already identified the resulting difficulties of attempting to solve the particular problem and, all things considered, are trying to offer us most painless solution. In a world where efficiency is important we can't simply refute all best practices. However if the addressed problem changes, or the technology surrounding it, then that best practice is out the window and we have to be willing to create new solutions.
The real issue here is that a lot of us are too quick to resort to best practices and design patterns before fully identifying the nature of the problem is and whether the best practice is the actual best solution. That being said, with all the propaganda surrounding best practice techniques and design patterns developers aren't entirely at fault. A developer who is not aware buzz of best practices and patterns or who does not implement them is not seen recognized as a "bleeding edge" developer in the eyes of the industry and potentially their peers. This sort of thing is ironic because best practices are hardly bleeding edge. Its this sort of mentality that becomes stifling to the development of new and better solutions to existing problems.
The real message here should be "use best practices when appropriate, but know when they aren't appropriate and determine your own best solution". Don't be afraid to question whether a best practice is actually what it claims to be.
Speaking as someone with a non-technical job, I want to back up Justin Reidy on this: best practices are useful for getting people thinking and working in the right direction, rather than for providing a simple solution to a problem. In my field (education), there are so many complexities, as I'd imagine there are in programming, and it's incredibly helpful to see what others have done that have yielded results. At the same time, I can't think of a time that we've taken a best practice and applied it wholesale to what we're doing without some modification. But this also goes along with your point: innovation arises out of this process. Great article, though. I really enjoyed it.
Good article. I like the idea that practices shouldn't be allowed to overshadow principles, but I agree with the comments that "best practice" need not be synonymous with "the only solution". When helping developers and architects solve a design problem it's often useful to have a starting point that's based on previous successes. As long as everyone on the team agrees that best practices aren't intended to be a one-size-fits-all solution I feel that both best practices AND best principles are useful.
Great post ..
I agree .. Usability and "Best Principles" are more important..
Not only is there too much emphasis on "best practices" and "design patterns" but try "methodologies" too. And to some degree "coding standards". These are all just tools that can make life easier or more difficult for initial coders and maintainers. But they can be abused.
OOPS as it is taught in college results in code that is so fragmented that it is as hard to maintain as the spaghetti code caused by Dartmouth's BASIC and its GOTO statement.
Is Drupal a true MVC? Who cares? MVC is just a TLA that may help development but is really important during an interview.
Even some "coding standards" are abused. While I bow to them in a team effort, I question many of them. The only benefit of too much white space over none at all is that you have room for notes. Why not use the white space intelligently so it shows its relation within the source?
Best practices are based on best principles.
I think it's a false assumption that best practices are never changing. Quite the opposite, they always change. As engineering time advances, some best practices change to adapt to the recent advancements in technology and new knowns. It mirrors science. Science is ever-changing, and our best practices relate to what we know now. As we learn more, some will change, but that doesn't make them poor solutions. They were based on sound principles -- it's just that the principles changed.
Yes, a good blood-letting won't cure many diseases anymore, but the doctors of their day based their solutions on the sound science of the day. And Steve Martin sure made us laugh with it anyway. :-)
Best practices are ideal solutions to well-known problems. These well-known problems have been countered day after day by some of the best, and worst, programmers of the last many years. Using the best principles known at the time, solutions were created to tackle these problems. Eventually, a pattern emerged, the common problem was discussed, the solutions analyzed, and the "best practice" was crowned.
What best practices ARE NOT are de-facto standards. The de-facto standard is certainly not the best practice -- necessarily. When in the case that a best practice is proven to be not so, it's likely that it occurred because the incorrect solution happened to be adopted by the masses mistakenly.
Only then is a best practice not so. But, then again, our knowledge of best principles is no less guaranteed.