Right Practice
Wow, it’s been a while since I wrote a post, sorry about that! I thought that I would take a brief break from the technical postings and espouse some opinion on something that has been bothering me for a while – ‘Best Practices.’
Best Practices have been around a long time, and started with very good intentions. In fact, one could easily claim that they are still produced with good intentions: To communicate methods that the hardware and software vendors recommend. However, the application of Best Practices has become increasingly abused in the field to the point where they have become more like prescriptions of how systems should be built. This has gone too far, and needs to be challenged.
Best Practices are a misnomer. At best, they should be referred to as Default Practices, because they are simply valid starting points for the implementation of a piece of technology. They do not describe the optimal (or even appropriate) recipe for implementation in every given situation. And yet: Best Practices are now becoming The Law.
It is increasingly difficult to deviate from a Best Practice, even when there are clear and logical reasons why this should happen. Best Practices are being used as an alternative to rational thought.
Consider this: Any given Best Practice is only applicable in a certain set of conditions. For example, it is ‘Best Practice’ not to fill a certain storage vendor’s array with its own SSD drives, it should only be partially populated. This has been prescribed by the storage vendor because the array has not been designed to cope with the high IOPs and bandwidth rates of every device in the array working at full, uncontended, tilt. This Best Practice is not saying that the SSDs will not work, it is simply saying that the full aggregate performance of all those SSDs cannot be sustained by the interconnects and processors in the array. Fair enough. But this Best Practice is being applied in the field as ‘SSDs are bad for the array’. What if your database requires consistent I/O response time of 1ms or less, requires masses of storage, but actually isn’t a very high IOPs or bandwidth consumer? Isn’t this the ideal situation to fully populate the array with SSD, to achieve the consistent response time and deliver the required storage density? The array will easily cope with the throughput and IOPs rate, thus negating the Best Practice.
There are many such examples as this. It’s time to stop using Best Practice as a substitute for good old-fashioned thinking, and start to implement designs based upon Right Practice: The ‘Right’ Practice for your particular situation. By all means, start with Best Practice documentation, they often have good information within them. But read between the lines and understand the reasoning behind those recommendations, and apply these reasons to your particular application. Are they applicable?
We are big on the Right Practice approach at Scale Abilities, it’s one of the reasons our clients get big value from our involvement. I recommend that you start to question the logic of Best Practices and start to come up with your own Right Practices.
Explore posts in the same categories: Full Stack, Generic, Oracle, Performance, SaneSAN2010, StorageTags: Best Practice, Right Practice, Scale Abilities
You can comment below, or link to this permanent URL from your own site.
September 16, 2011 at 10:06 am
Love this post, it is spot on.
So so often the solution to something will be that other catchphrase: It Depends. Yet people will blindly follow “””Best Practice””” as an alternative to engaging their brains and truly understanding a problem.
September 16, 2011 at 10:25 am
[…] If you only read one blog post this month, read James Morle’s eloquent attack on the term “Best Practice”. […]
September 16, 2011 at 11:15 am
Love it, support it 100%!
There’s just one problem with it (for the masses):
“But read between the lines and understand the reasoning behind those recommendations, and apply these reasons to your particular application.”
…this actually requires you to think rather than sheepshly copy and execute!
September 16, 2011 at 1:47 pm
[…] are still produced with good intentions: To communicate methods that the hardware and software … Read Morevia James Morle’s BlogTags: best practice, right practiceLeave a Reply Cancel replyYour email […]
September 16, 2011 at 2:01 pm
Welcome to the BACABP (Battle against calling anything Best Practice). Your example is well selected and well written. You propose doing exactly the right thing for the situation and yet an unenlightened rules follower would often be successful in preventing your customer from doing what is actually best in the name of following the vendor’s generic advice.
September 16, 2011 at 2:57 pm
[…] blogs less, but when he blogs, it stays blogged. James Morle has written a gem of an […]
September 16, 2011 at 4:05 pm
The Best practices and ROTs of my one database are not for my other database. They are so specific and they volatile too. Because they depend upon the data which my databases hold, and data changes in every aspect.
September 16, 2011 at 9:31 pm
Any ‘Best Practice’ that doesn’t include a “Why” should be analysed until it does. That was a “Best Practice to use ” may be revised into “Best practices is to ensure that the product used is well understood by several team members”. That sometimes opens up the option of a “Plan B” (use product A or train people in product B)
September 16, 2011 at 10:02 pm
I think you put your finger right on the problem: The Best Practice for Best Practices is to delineate the conditions. Thought is required for any variance from those conditions.
Another consequence is that standardization reduces cost. Imagine if you could use the same hardware and software simply by scaling up in a grid. What if that were commodity hardware and open software with only limited conditions allowed? How many bespoke hardware vendors would fall over dead if… oh, what? Never mind.
September 17, 2011 at 5:25 pm
[…] Great post from James Morle. Consider it required reading (and thinking). Wow, it’s been a while since I wrote a post, sorry about that! I thought that I would take a brief break from the technical postings and espouse some opinion on something that has been bothering me for a while – ‘Best Practices.’ Best Practices have been around a long time, and started with very good intentions. In fact, one could easily claim that they are still produced with good intentions: To communicate methods that the hardware and software … Read More […]
September 30, 2011 at 6:49 am
[…] – Should ‘Best Practices’ be renamed ‘Default Practices’? James Morle – a key storage expert – […]
September 30, 2011 at 11:21 pm
I like that.
Best Practice for Best Practices is not to call them Best Practices.