Pattern - Zero Configuration Options

This is an interesting idea: why not ship applications that have no customisation options?

Features

• Applications do not offer the ability to tune the application through changing various parameters.
• Some system state may be derived from the underlying OS (e.g. proxy settings)

Advantages

• Eliminates all possibility of configuration changes stopping things working.
• Radically simplifies testing, though OS-derived options may still need checking.
• Simplifies documentation and installation process
• Keeps the application in sync with the OS settings.
• Radically simplifies the support process "what have you done?"

Disadvantages

• No way to customise the application to a particular environment.
• No way to 'tune' the application.
• Users often like the option of tuning a product, it gives them control, or at least the illusion of control.

One application suite that adheres to the 'zero options' methodology is the Gnome Screensaver family of screen savers. They have rejected requests for a settings dialog, a philosophy which has some validity, but that puts them in conflict with downstream users of the product.

It is clear, therefore, that even for an application as non-critical as a screen saver, many users have expectations that they can somehow customise the application. For something complex, like a database or an application server, expectations may be even higher. However, do users really, really want to spend hours tuning the garbage collection policies of the application server, or indexes of the database, or do they just want something that works out what the appropriate options for the specific installation actually are?

As an example of this, the Sun JVM has the option -XX:MaxPermSize to control the size of the permanent generation part of the heap. It also has an error, OutOfPermGenHeapSpace which is raised when this heap is full. The JRockit JVM does not have a split between permanent and transient heaps, and so does not run out of Permanent Generation Heap Space, except when the entire heap is full. Accordingly, it does not have any equivalent of the -XX:MaxPermSize option -the entire problem has been eliminated, along with the tuning parameter.

SmartFrog support

Even though SmartFrog can be used to build custom applications, there is no requirement for the configuration options to be pushed out to the end users. They can be given a self-contained system that is integrated and consistent, one that works out the box.

• SmartFrog itself offers tuning options in default.ini; these control the JVM itself. We've tried to give a default set of options that are secure yet usable, though developers will find enabling stack traces very useful.
• We (and the Ant team) have experimented with requesting that the JVM determine the proxy settings from the OS itself. It works most of the time, but when it goes wrong, the developers are left fielding the support calls.