About a year ago I paired on the certain problem with a client tech lead. I wanted to hard-code some stuff in a PHP class, he wanted to externalize this configuration to the database. After all, he convinced me that we should do it in the the database. Cool.
It appeared that one of the managers heard the whole discussion. Then, during iteration kick-offs and some other different occasions he used to say: “please don’t hard-code it“.
I asked one dev lately why did he externalize certain piece of configuration (I could bet my head that it was never gonna change).
He said: “I didn’t want to hard-code it and it’s only 2 more properties in the configuration file”.
So I told him about YAGNI. And I told him that our wonderful configuration file has now 230 properties. Oh by the way, we use 10 of them.
Hard-coding is such a dirty word.
On my current project, only Spring is configured in 120 xml files, proud 1 MB in total. I think entire universe is configured there.
My theory is that many people think that if it’s not in xml then it’s hard-coded. And since hard-coding is such a dirty word… well everything ends up in xml or properties file.
Maybe I’m weird but I prefer to configure my java apps using java, ruby apps using ruby and so on. Fortunately I am not the only one!
- In guice you configure dependencies in java code. I waited too long for that. Thank you guice.
- Rails apps have only few lines of configuration (database settings) and everything else is pure ruby code.
Configuring is such a noble thing. It’s just wise to remember that configuring is not equal to xml file. For java apps I tend to configure in java:
- it’s smaller, more KISSy (no supporting code to read configuration).
- lets me use refactoring tools to change configuration (e.g: in Spring you have to keep xmls in sync with your java refactorings).
- lets me use compiler to validate configuration (e.g: there is absolutely no way you can set “dummy” to the integer field). I can focus on solving problem rather than implementing configuration validation.
- usually doesn’t require documentation. Provided that class/method/variable names in your code are sensible. And I’m sure they are.
In the old days distinction between hard-coding and configuring was clear: written in C++ class = hard-coded = bad; written in script/properties file = configured = good. Unfortunately this understanding of hard-coding is still valid today: some think that having a constant in java class is dirty, let’s then add a new property to the system!
Sometimes externalizing configuration is perfectly valid, but it applies only to small number of properties. Those are usually: different on various environments, changed frequently, changed by non-developers, etc.
In the world of Configuration Over Hard-coding my stance is Hard-coding Over Over-engineering. Sounds a bit stupid but I couldn’t think of anything better.