Config Code Creep

In the course of developing an application, many constraints are applied to the efforts of developers. There are, among others, the pressures of code re-use, extensibility and configurability. A beautiful application will be both extensible and configurable, and if it needs to be modified we won't have to throw away or re-write much of its code.

But extensibility and configurability can be taken to an extreme, and often are. Think about it. Conjure up a mental picture of the ultimate extensible app. Do you have it in mind? If you took the thought far enough, the application you're thinking of is indistingushable from a programming language.

It's possible to make an application configurable to the point of absurdity. What we end up with is minimal code and a host of configuration files (or database tables) that specify most of how the application behaves. But what are these configuration files really? They're code. They just happen to be code that's tucked away one meta-level down and likely has little or no error checking. Further, they're usually written in something clunky like XML, editing which is both tedious and error-prone.

To add insult to injury, developers usually don't show the same respect for configuration files as they do for code. For example, they're often second-class citizens in a CVS project. Developers who work with multiple branches of the same project often don't feel compelled to keep config files consistent with the rest of a branch. Nor is there the same compulsion for code re-use. Any programmer worth their salt wouldn't dream of copying and pasting a method multiple times into various source files, but they generally don't have a problem with pasting XML stubs into various config files.

Another example is a project I witnessed the launch of a few months ago. It was an ASP.Net application, and the default VS.Net configuration file was accidentally deployed to the production site. They simply weren't paying attention to it.

Then again, an example from the other extreme was a Smalltalk project I worked on where the configuration was written in Smalltalk code like the rest of the application. LISP applications are similarly often configured with LISP programs. That's perfectly respectable in my opinion. Certainly moreso than doing half your work in Java and leave the rest of it to ferment in XML files.

The take-home point is this: There's not a whole world of difference between code and structured data. The config files for your application can quickly become more complex and convoluted than the application code if you're not careful. It's often better to solve a problem in code, where at least some rigor is enforced, than delegate its solution to configuration.