Previous Up Next

Chapter 2  History

2.1  Introduction

In this chapter, I provide a brief history of the gestation of Config4*, from its initial conception to its first public release 14 years later.

2.2  Motivation

In 1996, I did a five-month consultancy assignment in which I helped a customer design and implement some client-server applications. When we started the implementation phase, we realised that the applications would greatly benefit from having a runtime configuration file. Unfortunately, we did not have a configuration parser to hand, and a quick Internet search did not turn up any suitable ones.

I remember thinking at the time that there must be countless developers around the world in the same position: they needed to write a configuration parser for a project, but deadline pressure meant they could devote no more than, say, a day to writing it, so the resulting parser would be undocumented, lacking in useful features, possibly buggy, and unlikely to be reused in future projects. The re-invention of mediocre configuration parsers by countless developers around the world struck me as being a massive waste of time. I decided that, once the current consultancy assignment was finished, I would spend a few weeks, possibly a month, of my spare time writing a good quality C++ configuration parser.

At the time, I was employed in the professional services department1 of a software vendor, and my employment contract contained a clause stating that whatever software I wrote—even outside office hours—belonged to my employer. At the time, my employer developed proprietary software exclusively (it would be about ten years before my employer started experimenting with developing open-source software), so I knew I would not be able to release my configuration parser as open-source software. This meant that, unfortunately, the wider world would not be able to benefit from my configuration parser. But at least my colleagues and I would be able to use it in our future consultancy assignments.

2.3  Development

I implemented the configuration parser. As far as I can recall, it provided only name=value statements (the value could be a string or a list), the concatenation operator ("+") and scopes. It was certainly a very limited subset of what Config4* contains today. One or two years later, a software developer in another department told me that he needed a configuration parser for a new product that was being developed, and he asked if he could use my parser. I gave him a snapshot of the source code. He modified the code to remove the concatenation operator (because it was unnecessary for his needs) and added some new features (which are outside the scope of this discussion). That modified configuration parser made its way into several new products. I mention that in case any readers are familiar with the Orbix or Artix products from IONA Technologies (since acquired by Progress Software) and recognise some similarities between their configuration file syntax and that of Config4*.

As Eric Raymond famously wrote in The Cathedral and the Bazaar [Ray99]:

Every good work of software starts by scratching a developer’s personal itch.

Once the configuration parser was mature enough to scratch my itch, I stopped work on it and went back to other things. But every few years I encountered a slightly more stubborn itch that my parser could not scratch. This resulted in me occasionally adding new functionality to the parser. Sometimes, I discovered that the parser’s architecture contained a significant limitation or misfeature, so I redesigned it several times over the years.

Eventually, my employer started to experiment with developing open-source software products. Soon after that, my employer agreed to transfer copyright ownership of the configuration parser to me, so that I could release it under an open-source license. However, I decided to add a few more features to the C++ implementation, write a Java version, and write comprehensive documentation before releasing it. I held off writing the Java version until I (prematurely) thought the C++ version was feature complete. This was to reduce the amount of work involved in maintaining two parallel versions.

2.4  Choosing a Name

I had struggled for many years to think of a good name for the configuration parser. However, one day a colleague mentioned the log4j project in a conversation; I realised that the name Config4J would be good for a Java-based parser, and this name could be adapted to provide Config4C, Config4Cpp, Config4Ada and so on. Hence, the generic name: Config4*, with the asterisk acting as a wildcard to denote the names of arbitrary programming languages.

2.5  Intertwining Development with Writing of Documentation

Years ago, I discovered a time-consuming but effective way to improve the quality of any software I was developing: write documentation for it. Writing documentation forces me to explain the various features of the software. If I find it difficult to explain a particular feature, then that makes me realise there is something wrong with the feature: perhaps it is badly designed or needlessly complex. This leads me to work in an iterative manner. I write the initial version of a piece of software. Then when I attempt to write documentation, I invariably become aware of problems in my software’s architecture. Then I fix the problems in the software before I continue writing the documentation. I tend to cycle several times—between writing documentation and fixing/enhancing the software—before the software becomes feature-rich, stable, and easy to use. This approach has served me well in my own personal projects that don’t have deadline pressure. I don’t know if such an approach would work in an environment where time-to-market is critical.

With the benefit of hindsight, I can see that at least half of the features in Config4* have come about because of my attempts to write documentation. So, if you think, “Ciaran did a great job designing Config4*”, and you wonder what is my secret for good design, the answer is that I do a mediocre design initially, and then slowly improve it by trying to document it. Of course, I never realise at the time that my initial design is mediocre. I always naïvely think that my design is great. It is only when the design has matured a lot, that I can look back and think, “Wow, my initial design was flawed in so many ways”.

For any readers not familiar with the term, professional services basically means “consultancy and training”. It is not to be confused with personal services (a euphemism for prostitution), although the hourly rates are similar. Disturbingly, there appear to be many other similarities between the two professions:

Previous Up Next