Coding, Configuration, Complexity

Something struck me today -- the replacement of code with configuration. This is all in the name of reducing complexity.This is good in some ways, but in many ways it's a lot worse.From one perspective, programming languages generally have these things that completely validate the input files. They're called "compilers." Same with the inputs and outputs of the code, there are many ways to enforce correctness at the compile stage of the game. Not only that but you can write unit tests (even though I don't much care for them myself) for the code using lots of good and modern frameworks. Further, you have good debuggers and support for crash dumps and all sorts of programmer aids.Configuration, on the other hand, is much more opaque. Configuration, when it's used for configuration is a necessity, and I'm not going to argue that in the slightest. Configuration, as it gets more complex, becomes a way of meta-programming the problem without any of the tools and utilities that come with compiled code.One advantage you do gain is that you can change the configuration without doing a deployment. But even there, if what you are deploying is indistinguishable from code, isn't that simply playing with semantics? The configuration deployment is code deployment, but in a different -- and arguably less reliable -- way.You are replacing a known, validate-able, construct with something that's completely home-grown and lacking in the tools that make programming a pleasant experience. In the effort to gain a bit of flexibility, you have traded stability for potentially unbounded complexity.Some times it's required.But every time you aught to think about what you're doing -- and not just do it because you think it would be a neat thing to play with.