Wednesday, November 26, 2008

Good, Bad or Ugly?

A lot of people in my office complained long and hard (but not loudly, of course) when the CEO suggested we come up with a set of benchmarks to objectively measure the quality and quantity of code that developers produce. I'm still forming my opinion on the whole matter, but the argument from many developers was that it's not possible to objectively measure who are the most productive developers because software development is different and special.

Remarkably, the same people don't seem to have any problem saying that they can tell you who in their team writes bad code (everybody but them) and who writes code too slowly (everybody but them again). To try and help out a bit I'm going to put forward the following set of measurements to gauge code quality.

1. Can you understand it?
This might look at first blush to be more a measure of the reader than the writer. After all, surely a decent programmer given sufficient time will be able to figure out even the most misguided and obfuscated code? Well, that's probably true, but there's a catch. If you're writing code to specification for a client then time is your perpetual enemy. If it's code you could understand after re-reading half a dozen times, stepping through using a debugger and a few terse emails with the author then you can't understand it in the context required by your job. In the time that took you would have been expected to find the code, understand it and fix the bug that's been reported in under the time in the project SLA. I don't care whether the code is extensively documented, self-documenting, uses line by line logging to describe its process, or whatever other method you prefer. If your company has a stated policy then it's probably best to use that, but the important thing is clarity.

2. Does it work?
This one is simple to define. Does the code fulfill its required purpose and nothing else? Figuring out whether or not it works is a lot more difficult. Working most of the time is not the same as working. That O(2^n) algorithm so many developers find abhorrent doesn't bother me at all as long as it works. Of course if the code in question can have n=1,000,000 and it needs to run in under a second then my guess is that it doesn't work. If it makes a call to an external system without safeguards and you can't guarantee the external system has 100% up time and is bug free, then the code doesn't work. Before deciding the answer to this question I suggest making sure you have a test process in place that can actually let you know whether the code works.

That's all of them. I know it's not entirely objective, but if the answer to these two questions is "yes and yes" then you're looking at good code. Not necessarily great code or perfect code, but good code.If you've got time to worry at code that is "only" good then I want your job.

I'm not saying that there aren't hopelessly incompetent developers out there, and if they're in your company then they need to be out of there as soon as possible. If somebody is committing code that breaks the build every day, doesn't write or update unit tests and hasn't had a positive code review in six months then I'll agree with you: that person is has to go. If the tests all pass and their code reviews are positive (and no it doesn't count if the negative code reviews come only from you) but it's not how you would have done it then I would advise you suck it up and get back to work. If you're getting mad at them because you have to look at their bad code under the pressure of fixing a critical bug reported by the client at 5 o'clock on a Friday then the correct thing to be angry at is the process that let the code get out into production in the first place.

Saturday, November 8, 2008

On Time vs In Time

Making the release date is generally regarded as a cause for celebration as the project has been delivered on time. A bigger cause for celebration would be if the project is delivered in time, by which I mean "in the number of hours we said it would take."