Tag Archives: Convention-over-configuration

Convention vs. Configuration (Part 1)

Is convention-over-configuration still rising? I’m not really sure it is, but it certainly has gained a lot of adherents recently. I used to be one of them. In fact, I was an enthusiastic adherent. But I’ve backed off significantly.

I’ve backed off partly because of my experience with a WCF-based framework I use at work. This library was designed very convention-ly. And nobody can get it to work. N-O-B-O-D-Y. And I’m not talking about slapstick developers here. Very intelligent devs with many years of experience have spent ludicrous amounts of time trying to get their services up and running in this framework, without success. That’s a pretty clear indication that you are doing something very wrong.

The problem with conventions is that they aren’t very discoverable. You can open a code file, stare right at a convention until your eyes bleed, and not even know it. Did the guy who wrote this class name it that way because he named it that way? Or does it have to be named that way? There’s a static method that doesn’t seem to be referenced. Is it dead code, or is there some reflection code out there looking for a static with that signature? And why the hell do I have to go through this nonsense just to get my code working? Convention-over-configuration is really only a great idea for the guy who comes up with the conventions. For everybody else it’s a guessing game. It’s just not possible to write code that says “it looks like you are trying to participate in my convention, but you’ve got 1 of the 5 requirements wrong, so it’s not going to work”. When you get a convention wrong, you don’t usually have an exception thrown, at least not a useful one. Things just don’t work.

Until we have the discipline to properly document everything we do, the conventions used in our code must be kept tasteful– small in number and obvious in nature.