Gratuitous Configuration

I have always been annoyed by developers who try to put every possible option into configuration files.

First, they inevitably fail. The space of possible application behavior is more than exponential in the number of actions the user performs. It is exponential in the amount of actions available to the user. This abstract fact has a simple practical result. Most changes requested by the business are not feasible by adjusting a configuration file, no matter how universal you try to make it. So you have gained almost nothing.

Second, they are difficult to use. Nobody ever documents these monsters, and you have to dig through code to figure out what you have to change, or whether the change is configurable at all.

I recently had an epiphany on why so many developers continue to use them. It is related to the fact that good application architects are about as common as flying pigs. There is a mindset that the code on large projects is expected to be a tangled mass of spaghetti. Since it will be virtually unmaintainable anyway, it is beneficial to set aside a fixed space of customizations which will always be possible. Configurations do just that. The more behaviors which are controlled by configurations, the more customization which will be possible.

I reject this mindset. I have never had trouble designing maintainable systems. My challenge has always been preventing self appointed experts from mucking up the architecture.