Hi Alex. Yes, excessive configuration is just as bad as excessive convention.

I think the movement of “convention over configuration” that occurred a decade or two ago, and which is still with us, was a reaction to the overly complex application server configurations of the day circa 2000. It was so bad that one would often see app server XML config files that were thousands of lines long. And it was brittle too, because it was XML — outside the typesafe syntax and consistency checking of a language based system.

People got sick of the complex configs, and Spring was one of the first tools to champion convention over configuration. But as so often happens in IT, it became a movement, and an ideology, and went too far in the opposite direction. Let me explain why I think so.

If someone uses a particular tool every day, say Spring or Rails, they learn the tool inside and out. At that point, convention makes sense: “This does not work: well the XYZ must not be in the QRS directory — aha, it is not!”

But for someone who does not use that tool every day, they would not know to look in the QRS directory. And with these kinds of tools, the conventions are often buried somewhere or poorly documented — one is expected to copy code from an example or template, but that does not help you to figure out why something does not work.

If everything must be specified as configuration, there is usually a definitive spec defining the configuration choices. Unlike Java app server configs, Java ecosystem “javadocs” are a great example: the culture of the Java ecosystem is to fully document and publish one’s APIs, and as a result, the ecosystem has a great history of maintainability and usability.

But if a spec is too long, then it is just as bad as relying on convention.

What we need is configuration/specification, but simple configuration/specification. Complexity is the problem. As you said, “Better for tools & languages to enforce only one way to do things.” So IMO, we should keep it simple, but explicit. Because if it is explicit, then newbies, or people who are “drive by” looking at your code and are not experts in the tool, can see everything that is specified and look it up and say “what is this for?”, whereas if things are implied, they don’t know what they are missing.

My argument rests on the assumption that one’s code will be shared with others outside one’s team. If that is not the case, then convention makes much more sense, since the members of a team quickly become expert in their tools.