Thursday, September 08, 2005

I've used this construct in many of my talks. Usually i refer to the "Default namespace" within an XML instance document and XPath queries problem. I am more and more convinced this is a general, and very underestimated, problem.

 

So, what's the issue? you might ask. Defaults are there for productivity and help with 'the initial learning curve'. But I'm starting to believe most 'defaults' are causing more harm than good.

 

The main reason of this more 'harm than good' is the tendency within these 'defaults providing applications or toolkits' to hide to much. By providing defaults in configuration settings, users of that system do no longer 'feel the need' to configure. They'll just use "the default".

 

Here is where we can make a separation between "probably bad" and "probably good". Noticed the use of "system" and "toolkit" in the previous paragraph? That’s one of our hints for, how we get to determine where a default could be good or bad.

 

Let me put forth this statement and try to elleborate:

 

Defaults are only good if used for non critical variables, they do more harm than good in any critical variable!

 

The main reason for providing defaults is productivity. Instead of having to go through specific instructions, configuration storages (file, registry, environment variables) and 'experience through time', defaults are intended to remove these learning curves and allow the system to operate according to accepted parameters.

 

The problem today is; What are the accepted parameters?

 

By having the vendor of the system 'choose for you' what these parameters are, we are totally at the mercy of this vendor’s insight. Recognizing this thread, most systems now come with multiple defaults. This brings back some of the 'choice power' to you, but its still not enough.

 

In most cases the defaults cover 'everything', but never 'your thing'. You will have to tweak the configuration defaults and learn how to do that. Skipping this 'learn how to' is usualy even forced from outside factors like 'time to market' and 'strategic board decisions'. Wizards have been created to help ‘skip learning this’ and press “next, next, next, finish”.

 

Some examples of defaults causing issues:

  • (allmost all) WebServices toolkits defaults promote the RPC approach
    Although the toolkits provide message based approaches, it is hidden by all defaults.
  • Default namespace usage in XML is still the cause of many issues
    This might be considered an XML-XSD-XPath specification/implementation issue, a 'non-experienced' user issue, but the fact remains that the default namespace is causing much confusion.
  • Default logfile locations cause security issues or break a system.
    Having a logfile point to "C:\Temp\MyLogFile.log" today is dangerous. The "Temp" directory might not exist, or have access rights protection.

All of the above mentioned 'defaults' where critical to the core functionality of the system.

 

 

Some examples of defaults being useful:

  • End user input.
    Users hate to 'repeat steps'. The less repetition, the better. Having defaults filled in and modifying a few is easier than filling them all in.
  • Editor assisted functionalities.
    Editors are for creation and manipulation of content, not for the system maintaining the content. Content that is not considered critical from a system point of view.

All of the above mentioned 'default' where non-critical to the core functionality of the system.

 

 

One remark often made against this reasoning is; "But the user should have known better!". To a certain extend i agree, but lets not hide this fact from them then! Lets force them to 'do this configuration & maintenance stuff' instead of hiding behind 'these same defaults that the users should have known about'.

 

So, what’s my default behavior? It’s pretty straight forwards and I like to call it the ‘common sense’ approach;

 

Reevaluate the weight of the variable for which the default is intended. If there’s any way this default could cause serious issues, side-effect or even break the system: Do not use a default! Document it clearly and force it as step of the configuration process. Make defaults them self configurable!

 

 

 

 

P.s. Of course I’m all for the creation of great configuration tools! With defaults to the max! But those are the defaults for the configuration editing tool, not the system for which the configuration is being edited. (did that make sense?)
9/8/2005 9:01:27 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [4]Trackback