The Costs of Configuration

A discussion on the Chicago Agile Developers' mailing list on the subject of installers turned to configuration and how often it is needed.

Philip Hall wrote:

In a world where software runs upon multiple systems with different architectures and conventions; and in a world where we write applications that are 'customisable' by the customer (to cope with their specific system(s) configuration differences); and in a world where these applications are becoming more 'dynamic' in nature - it is very unlikely that you won't need a installer to overcome these 'set-up' issues.

Robert C. Martin wrote in reply:

I've taken the view that although external configuration may be necessary, it is always a liability. Every configuration item is a liability, whether it be in a config file, the registry, a new tag in an XML file, or whatever. I strive to minimize, or even eliminate, external configuration items if at all possible. At very least I strive to create a configuration neutral default.

I think Martin is on to something. Configuration can be a way to hide or postpone complexity. If this is inherent complexity, well and good. That's why Fred Brooks said there is no silver bullet. Software is hard and I'd rather edit configuration files than add too much complexity to the core software.

On the other hand, if I resort to configuration instead of reducing complexity I am incurring technical debt. There are two forms of complexity that I may be failing to reduce.

  1. the complexity of storing and reading configuration information and changing the behaviour of the software accordingly
  2. the complexity exposed to my customers who have to learn how to configure the software before they can use it

There is a temptation to make the software configure itself. If it can detect its environment and configure accordingly, that hides the complexity from the user. Alternatively an installer with a "wizard" interface can walk a user through the possible choices. Neither of these approaches reduces the first type of complexity.

Martin's example is fitnesse:

This is a web delivered acceptance testing tool written in Java. It runs on windows, macs, linux, and anywhere else that supports the java environment. One of our goals was: "Download and go" meaning you should be able to download it and run it with no configuration and no setup. This meant that we couldn't trust it to an external webserver, so it servers it's own pages. We couldnt' trust it to an external database, so it saves its own data in flat files. There is no installation required other than downloading it, unzipping it, and running it.

The tool is neither a general-purpose web server nor a real database. Obviously there are things that the more general programs do better. If it can do the job well enough for its purposes, nobody will care. No matter what web server or database software the users currently have and no matter how often they change versions, fitnesse will continue to run.

Sometimes configuration is valuable enough that the pain is worth it. Every user would like the software to use their language. Sometimes a user will even pay more for that privilege. Software that automatically detects the right language and uses it is beautiful to behold even if the innards are ugly.

About this Entry

This page contains a single entry by Christian published on October 3, 2003 4:13 PM.

Rawsthorne: Mixing a Process Cocktail was the previous entry in this blog.

Automating web application tests is the next entry in this blog.

Find recent content on the main index or look in the archive to find all content.