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.

Principle #1: Prove it!

OK, so if we’re going to base our profession on a more sound foundation, we should probably have a set of principles to work from. Here’s my proposal for the first:

Writing code that works isn’t enough. We have to be able to prove it. The necessary corollary is that it’s unprofessional to take offense when someone asks us to. I think anybody on the team ought to be able to walk into my cube and say “You know that code you wrote last week? I’m not convinced it works. Prove it.”. And not in some hypothetical kind of way. It should actually happen once in a while.

Like most developers, I work for a for-profit company. That company continues to stay in business by selling a product for a dollar that’s worth two dollars. And nobody has any problem with our clients keeping us honest. When we make a release available to them they don’t install it right away. They test it first. And they’d be nuts not to.

Why should my relationship with the company be any different? After all, there’s a lot at stake when I check code in. If nothing else, people’s jobs. People with mortgages and kids. And increasingly, software is taking on critical jobs– like the code I write in the medical field– where people can get killed.

Killed.

“Prove it” is the least we can provide.

On one of the most important developments in our profession

Automated unit testing. Automated unit testing is one of the most important developments in our profession.

If we’re going to create a true profession of software engineer, we need to build a more rigorous foundation. Lets get started.

We write methods. When you write a method, how many ways are there for it to not work? A lot. A truly, uncountably, mind-boggling number of ways, even for a short method. Now, how many ways are there for it to work? Not many. In some cases, only one. So, in the absence of evidence on the matter, we must assume it doesn’t work. Because it probably doesn’t.

One of the forms that evidence can take is automated unit tests.

There are so many things I could expand upon in this post, but I’m trying to keep my posts as short as possible (but not shorter, as Einstein might say). So let me end the post with this: I’m not OK accepting a salary for writing code that doesn’t work. Seat-of-the-pants programmers get paid to write code. Software Engineers get paid to solve problems.