Thoughts on Convention over Configuration

Having spent the majority of my professional life on Windows with .NET, I'm not much of a Java troubleshooter. I speak the language and am familiar with a slew of frameworks, but I just don't know the JVM like I know the CLR. Yet.

Additionally, I notice that the Java community loves to follow the newest hottest thing far more than the .NET community. One example of this is Java's love/hate relationship with XML.

Back when Enterprise Application Integration (EAI) was the hot buzzword, we started to see a lot of configuration done in XML. XML Configuration files became huge and unwieldy. People started to talk about "XML Hell" and eventually, we started moving towards "convention over configuration".

I'm a fan of focused, opinionated software - and I definitely think convention over configuration is the right way to go in the majority of circumstances... but some people have gone beyond convention over configuration into: loathing and avoidance of XML in all circumstances.

Eclipse, for example, uses an eclipse.ini file to provide bootstrap arguments like the location of the JVM. Its convention is argument name on one line followed by argument value on the next line - which is the standard convention for ini files. My problem was that I haven't edited an old-school ini file in so long that I just forgot the convention. I had argument and value on one line.

Now, it's entirely my fault for forgetting the convention, okay? I admit that. Everyone should know ini config file conventions. But if the config file had been XML, it wouldn't be possible for me to forget the convention because the XML would have just been invalid. Instead of getting a non-sequitur Maven Integration Warning about running on a JRE instead of a JDK, I could have gotten an exception that said the configuration is bad. In addition, given a schema, I could have verified the configuration file myself.

Don't be confused about what I'm trying to convey here - it's perfectly fine that eclipse uses a well-known convention (ini) for its configuration. I'm trying to get at something more important: when to choose "convention over configuration" vs "configuration over convention". I think that the answer is tied to the concept of friction.

Troubleshooting this problem I had definitely counts as development friction. Since the goal of software engineering is to deliver the maximum value to our customers, reducing friction has a direct correlation to customer value. Therefore, we ought to choose convention over configuration when the benefit of learning or remembering a convention outweighs the cost of learning or remembering it.

In the example of the eclipse configuration, the benefit of editing an ini file over an xml file was ZERO, and the cost of remembering the convention was non-zero. Again, this example is contrived because the non-zero cost was due to my forgetfulness - but the example holds for other conventions that are less obvious. Do not create your own little convention and make me learn it just so you can say you use convention over configuration. If you are designing a framework, do not cause my NET amount of friction to increase.

For me, this begs the question: how do we objectively measure the cost of a given convention? To the convention's author, the convention will seem "obvious" and therefore cannot be an objective observer.