Friday, September 29, 2006

Are "best practices" really any good?

Why did somebody pick the term "Best Practices" to describe something very often constituting a local optimum in efficiency space? I find it very hard to believe that all approaches described as "best practices" are equally good or even fulfill the label "best practice" at all. Lets for example examine two approaches that seems to be fairly popular, and seem to at least think they represent "best practices". The first, patterns, is fairly technical in its offering and close to the code while the second, ITIL is more management related.

Patterns have a clear area where they are applicable limiting their scope. Patterns are can be used, copied and most importantly improved by anyone. Patterns are in a sense open for improvement. Patterns seems to have spread rapidly to use into real life applications, some patterns obviously more than others. Embracing patterns has been made fairly easy. Inefficient code can be reimplemented using patterns by a technique called refactoring. Some tools are even claimed to automatically refactor for you at the press of a button.

ITIL is described as a collection of best practices, but is it really as efficient as it can be? I would state that it is too early to say although ITIL has been around for some years. ITIL is however only in the process of being broadly adopted. ITIL seems more proprietary and does not seem to welcome feedback to the same extent. This limits the people working on improving the offering to only those that work for the agency. In stead ITIL seems more focused on providing training and certification at a price. Migration to using ITIL processes is left to the organization perusing excellence. ITIL also seems fairly vague in terms of limiting applicability.

A "best practice" should logically be something that is coming fairly close to being as efficient as possible. Many patterns fulfill this requirement. ITIL i would say is a good practice, at least in some respect, but in others seem fall short of being a "best". I don't think the difference in technical dept between the two examples i picked is fully responsible for all differences.

Some are often baffled by the fact that a bureaucratic approach like ITIL is even considered a good approach. Everything however depend on the problem you have at hand. If you need to only manage a single server used for a non critical application used by a single user to serve his own blog entries ITIL is probably just as overkill as writing this application using every existing pattern ever documented. For a major fortune 500 enterprise in Europe ITIL may however be a very good approach to fulfill legally mandated governance of financial applications.

What i mainly disappointed in is the failure of "best practice" promoters to recognize and efficiently communicate the known limits. One major key to efficiency in IT lies in knowing what is suitable. In a similar way one of the major reasons for failure is belief that one approach would be suitable when it in reality is not. Marketing seldom gets the limit across. In the mean while until there is a non subjective declaration of content for each approach the best solution is to be skeptical of all "best practices" and carefully evaluate their merits. And yes, i would prefer that the "best practice" promoters would in stead start to talk about good operating practice.

Thursday, September 14, 2006

Efficiency in IT

Defining efficiency in IT is harder than defining inefficiency. Inefficiency could for example be defined as when resources/time/effort is wasted in IT functions.

There is nowadays much talk about efficiently aligning IT with business. IT functions should be getting the right things done in an agile manner as requested by the business. There is some merit to this, but mostly its just empty talk. If business have no clue what they want, or if business have no way of communicating what they need you will not either get any efficient aligned IT function for your business.

You must to a large extent know what to do from all stakeholders point of view in a balanced way. Some unfortunately tend to understand that business alignment only mandate implementation of the often arbitrary requested features. Truth is that a successful efficient system must fulfill needs raised by all stakeholders regardless if they are business representatives, technical deployer or help desk support professional. Some requirements are more important than others, but letting one part decide on priorities is not wise.

This does not mean that ALL functional or nonfunctional requirements should be implemented. It is equally important to be able to disregard all not well thought out requirements. Featuritis is a dicease where often business are forced to prematurely state all requirements up front (as done for waterfall projects) to be sure that they don't need to be involved in any cumbersome change management process intended to limit changes more than fulfilling any other need.

So how do you know what to do? One thing you could try is to ask me, but ill just answer that I don't know... The key, if there is any, is to involve everybody in your quest for efficiency. This has been shown to work in factory settings, so it should work in any setting. The people doing the work that will be affected by the change should know what can be done better and where it will lead, but getting the ideas out into the open will take a bit more than just asking for comments in a email message sent to all. An other thing to rely on is experience. If you don't have experience you have a good opportunity to acquire some by trial and error.

An useful guide to efficiency is to keep the spirit of Occam's razor in mind, or try tp do everything as simple as possible, but no more simple. Excessive complexity leads to waste, or aspects that will never be used that will be in the way of further development.

Nature has a couple of important lesson for us to learn. Always start small and evolve from there. Kill of bad ideas often and early, before they become multimillion failures bringing the whole company down. Everything does not need to be perfect, just good enough will do. Interaction with stakeholders and suggestions for small changes should be welcomed at every opportunity. The ability to test out new small features in a cheap way without substantial risk can be one source of efficiency. Doing small nondisruptive changes quickly is why agile movement is pushing. Note however that any agile approach by itself will not guarantee efficiency.