Configuration is Not Better than Code
From Zanecorpwiki
There's a vein of thinking that says any reduction in code is good. This is often combined with the idea of a framework to produce a configuration based approach to application development. This is almost always a bad idea.
Obviously configuration is overall a very good thing. It's much better to have 100 small config files than 100 versions of your application.
Even configuration based development is not all together a bad idea. Log4J makes good use of configuration.
Log4J works, though, because it's a secondary system that's not involved in processing.
On the dark side, you have things like the Spring Framework, which turns authentication into a configuration. The idea: you just throw requests to authenticate to the spring servlet and you're done. The problem is:
- Authentication is one of those trivial things. Sure it's tedious to write authentication every time, but even if that was the alternative, it's not that bad.
- If you have develop lots of apps, make a library, but do configuration in regular code.
- The worst thing you could do is hide authentication in an inaccessible library that you configure.
The problem is that whenever you run into the need to do "something different" and you're using a configuration based system, you have to stop your regular coding and figure out how this entirely different and idiomatic paradigm of "configured services" works. You can't use any of your existing tools. Not only is it not obvious where to start digging into the process, it's often quite hard to even figure out where to begin figuring out how it works. You can google for mountains of docs, dig through the code and try to find where the config is and hope it remarks on whatever you're trying to do.
Then, after all that, you might find you can't even do what you need to do.
