Best Practices for Best Practices
Like many other industries, IT industry has all sort of best practices, from how to use a product to how to design software. I have personally contributed top 10 best practices on how to use VMware vSphere APIs (part 1, part 2).
Given the complexity of IT systems, it makes sense to capture the expert knowledge in the format of best practices. I think there are just too many of them and not all of them are of high qualities, thus I have a mixed feeling about best practices these days.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
On one hand, some best practices do help design and run a good IT system. If you follow these best practices, you will have an effective and efficient system, be it software, hardware, or service. On the other hand, there are sometimes too many to pick from, and too many pages to read through, not to mention the bad advice under the name of best practices.
What should be best practices? It takes for sure lot of domain expertise to answer this question. I am not expert in all domains, so I would try its opposite question: what should not be best practices?
In the following, I list three categories of them:
- Bad best practices. These are namely best practices, if followed faithfully, lead to confusion and bad consequences. After all, everyone can claim best practices for what they have come up with. I’ve seen many cases in which lousy programmers talk about best practices writing code.
- Common sense best practices. It’s good to guide by common sense in IT world. Writing down these people already know about it just does not help much, but a waste of time. Having said that, the definition of common senses may vary from person to person, depending on education and experience. Something obvious to one may not be so to others. It’s up to the author to do more homework to understand audience.
- Programmable best practices. These are best practices indeed, but should never be documented on paper. Rather they should be coded in applications. Not all the best practices are easy – some actually involve quite some analysis and steps to switch on this, tune that, which requires good understanding of a system. Although you should have all the basics when you read the best practices, it doesn’t mean you should go through these which can be best implemented in the software.
If the software can do it, it should! Don’t bother human in the form of best practices. Besides the existing software that can include best practices, I see the rise of best practice software tool on its own soon.
As expected, software cannot do everything, for example, the big picture beyond the software, how to use the APIs. So there are plenty of chances to blog about best practices.
I hope these rules are helpful. Aren’t they best practices for best practices? You decide.
Lastly, one simple but probably the most important best practice for readers: only read and follow best practices from the best practitioners. I couldn’t emphasize it more.