Full-stack Philosophies

James Morle's Blog

RSS Feed

Right Practice

Posted on 9:03 am September 16, 2011 by James Morle

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.


15 comments on “Right Practice

  1. 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.

  2. Pingback: Friday miscellany « RNM

  3. 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!

  4. Pingback: Right Practice (via James Morle’s Blog) | Structured Data

  5. 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.

  6. Pingback: Log Buffer #238, A Carnival of the Vanities for DBAs | The Pythian Blog

  7. 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.

  8. 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)

  9. 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.

  10. Pingback: Right Practice (via James Morle’s Blog) « Ukrainian Oracle User Group

  11. Pingback: State of Data #68 « Dr Data's Blog

    • Hi Senthil,

      Thanks for the comments. I do have a book project planned, but not about 11g! I can't tell much more for now, but more details will be forthcoming shortly, I hope.

      James

Leave a Reply