Catalysoft   Turtle
home products articles about us contact us

Is Configuration Really Easier Than Programming?

In the "Good Old Days" of programming, you wrote everything from scratch. It was hard work, because you had to think about all aspects of the software, perhaps including tricky issues such as security, protocol handling, pool management, or transaction handling. Solving all the problems probably took quite a while. The advantage was that you thought about all the issues involved, and you devised a solution which you understood.

These days, everyone talks about 'containers' and 'frameworks'. These pieces of software infrastructure are designed to take the drudgery out of some of the common aspects of software development. On the client-side, a graphical user-interface container might manage the enabled states of the menus, receive actions from the user and control the behaviour of reusable 'plug-in' components. On the server-side, a container provides support for security, transaction management, database access pooling, object pooling, and so on.

In general, this is probably a good thing and I approve of the fact that developers are freed up from some of the 'drudge' work, so that they may concentrate on the aspects that are particular to their business.

However, the move from programming to configuration is not without its drawbacks:

  • Unclear semantics - The meaning of configuration parameters is often not clear to anyone but an expert user of the tool. This makes configuration a highly specialised activity that places demands on the personnel make-up of your team.
  • Unshared semantics - Different tools are configured in completely different ways. If a project combines the use of several different tools, you may need several tools specialists!
  • Hidden implementation - If you do not understand some of the configuration parameters, and, as often happens, the documentation is poor or non-existent, you are pretty much left on your own. It is not usually practical or possible to look through the source code to 'work things out'. It is more likely that you will embark first of all on a fruitless search of the web, finding many other people asking the same question but none with any answer, followed by a brute-force enumeration of all the possible, feasible, plausible combinations of values of the configurations in the hope that one combination will have the desired effect. Of course, even if it does have the desired effect now, with the data currently provided, it is a pure leap of faith to believe that it will always have the desired effect.
  • Overly complex solution - Often, your problem could be solved in principle by writing some custom code and configuring only a part of the reusable tool's functionality - you are not interested in the rest of the functionality that it provides. However, to get it to work, you may need to configure even the parts that you are not interested in. This may mean that you need to learn about functionality in which you have no interest, or you may get stuck and frustrated, feeling that the tool is getting in the way of your progress because of its expectations and assumptions.

To mitigate these problems we need a clearer semantics for configuration parameters, either through more appropriate and better quality documentation, or by a self-documenting approach that leaves the developer in less doubt about the meaning of a configuration parameter. We need commonality between different tools, so that learning a new tool involves a less steep learning curve. We need tools that involve minimal learning and configuration overhead when used for simple tasks.

It seems to me that configuration as an activity is still in its infancy, and that we still have much to learn about how to derive benefit from reusable, configurable tools.

SW, March 2003.