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:
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.