Clojure is a relatively new language to appear on the Java Virtual Machine (JVM), although it draws on very mature roots in the form of the LISP langu ...
Recently, I (Adil) was invited to participate in a one day seminar on the subject of Requirements Engineering. Whilst I have no direct experience of t ...
To attract all potential customers to your business you need a presence on the web. The problem is that if you haven't set up a website before, you p ...
LISP is a general-purpose programming language and is the second-oldest programming language still in use, but how much do you know about it? Did you ...
From a developer's point of view use of open-source tools has advantages beyond the obvious economic ones. With the open-source database MySQL in mind ...
Is Configuration Really Easier Than Programming?
In the Good Old Days of programming (say 20 years ago), you wrote everything from scratch. It was hard work, not only because you were rarely able to plug in existing third party components to expedite project development, but also because you had to think hard about all aspects of the software to be developed. Some aspects, such as scalability, security, interoperability, resource allocation, or transaction management, might have been particularly difficult to tackle, especially if you were working as part of a small team of developers. You might have made a good effort to solve some of the difficulties, but devised ad hoc solutions to others. And solving all the problems probably took quite a while. The advantage, I believe, was that you thought hard about all the issues involved, and you devised a solution which you understood thoroughly.
The New Age of Programming
These days, everyone talks in buzzwords. Some new ideas and some old ones are borrowed, rehashed, renamed and resold as 'the latest craze'. The developer's world is a bewildering landscape of ideas, hype, progress, distraction and information overload. And software development is no longer an isolated process - every developer is 'networked'. If you have a question that you and your colleagues can't answer, you invariably turn to the Web to first pose the question, then sort the wheat from the chaff in the answers provided.
The way that a software application is built has changed too. You can't afford to start from scratch because it would take too long, and your end-product would likely be inferior. (And of course, your competitors don't start from scratch either.) Instead, you embrace rapid application development, code reuse, components, frameworks, and, latterly plug-ins and containers. Containers are software infrastructure components that 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 graphical user-interface plug-ins. On the server-side, a container (for example, ) provides support for security, transaction management, database access pooling, object pooling, and so on. A move toward container technologies is widely seen as a real boon for developers (as well as their employers), as they are freed up from hardcore software issues and can concentrate instead on aspects of code development that pertain to their organisation's business (the so-called 'business rules').
For the developer, the shift to a container-based approach introduces a new task - configuring the given functionality of the container. I believe that in the rush for quick and easy application development, this new task has been largely overlooked. Software engineers and their managers have assumed that the configuration task is easier, and therefore preferable, to the equivalent programming task. Now, without questioning the overall benefits of the general trend, I should like to point out that 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.
What is Needed
To mitigate these problems, I believe 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;
improved validation of configuration parameters at tool start-up time (or earlier);
improved error messages for mis-configured tools;
the evolution (or even design) of accepted standards.
We also 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. And we also need to know how to interpret problematic and exceptional behaviours due to improper configuration of the tool. In short, the risk for your project is that if your container is poorly understood, then any problems that arise could be very difficult to fix.