Best Practices

While I was fixing my Google Reader feed for BusinessWorld‘s IT Matters site (they changed from http://www.itmatters.com.ph/RSS/itmatters.rss to http://www.bworldonline.com/RSS/itmatters.rss), one article caught my eye:

IT needs best practices, too!

My first reaction was, “No sh*t, Sherlock!” After reading the article and finding out that it’s not talking about software engineering practices (which I am sure isn’t being practiced by many local software houses) but the low adoption rates of best practices in Auditing and Risk Management in IT departments, my reaction was still “No sh*t, Sherlock!”. I mean, if you’re dealing with foreign clients and yet you’re not familiar with those processes then you have a big problem on your hands. Either that or you know a good place with steak and strippers.

Since we’re at the topic of Best Practices, I might as well cover it in this post.

—

The gap between the best software engineering practice and the average practice is very wide—perhaps wider than in any other engineering discipline.
-Fred Brooks, Jr. The Mythical Man-Month “No Silver Bullet”

I can’t seem to find any good definition for “best practice” in the documents and books I have at hand so we’ll just make do with the Wikipedia definition: “a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc.”

For example, using a screwdriver is the best practice for joining things together with screws. You obviously won’t use a hammer (a “bad practice”) for driving screws.

Best practices are also dependent on the context, something that a lot of people don’t understand (more on this later). Back to the screwdriver example, sometimes a hand screwdriver isn’t enough for driving screws. There are cases where you would need power screwdrivers, and other cases where you’ll need to pre-drill the hole and attach tox/anchors in it.

Not that difficult to understand, right? Unfortunately, the adoption rates for software engineering best practices is low in the IT industry.

The main barrier of entry is, in my opinion, NIH. Software development looks easy from the outside, so it’s understandable that software houses would prefer to just work things out on their own. The reaction to best practices is usually like this: “Why should we attempt to adopt practices which have been proven to work in the appropriate situations for years when we’re already ok on our own? Heck, our practices may even be better than those practices!”

Cringe worthy, right? Get used to it.

On the other side of the spectrum lies another barrier for entry: managers turning “best practice” into a buzzword.

The problem here is that PHBs consider best practices as panaceas and that merely adopting those practices will put them on top of the competition. Aside from the problem of using these practices out of their specific contexts, blindly adopting practices is generally bad.

Improper application of practices also results in employees becoming skeptical of future adoptions of best practices. This should be a good approach to best practices, if not for the fact that employees tend to dismiss best practices outright instead of just being skeptical.

—

To sum it up, don’t hesitate to research and adopt best practices, but don’t think of them as panaceas.