The Thirteenth Step

Well, as the title clearly states this blog is "on everything", so today I want to talk a little about software development in general. I have been interested in software development and related topics for quite a while now, and if I would have to name one person who had the most influence on my views and opinions on the subject it would without a shadow of a doubt be Joel Spolsky.

Back in 2000, Joel has introduced a Test to measure how good a software company is using twelve simple criteria. The Test is very useful, in fact, it is successfully used to rank software companies that appear on Joel's job listing site, and provide a great reference for job hunting developers.

One thing, however, bothers me a little, and it's an issue of a "code review".

A "code review" is, naturally, a process in which a portion of written code is read and examined visually by programmer's peers or superiors short time after it is written and usually before it is committed to a next build or release. This is by no means a definition, "code review" has many uses, but it's the phrasing I would use for the purpose of creation of another step in Joel's test.

"Step 13: Do you have a regular code review? "

Maybe it is so trivial that it is implied and maybe not, I think it is worth mentioning explicitly and I will try to explain why.

Although most would agree that "code review" is a useful and effective practice for continuous improvement of code quality, not everyone is actually doing it, to any extent. The reasons, or to be more precise - excuses, ranges from "I am the best programmer they have there, no one can review MY code" to "We would be glad to, but it takes too much time to review all the code we write here". There are also those who say: "We are so agile, we review our code as we write it". Well, if all your code is written in pairs, then I think you are covered.

It does not take a programming genius to review somebody else's (even another genius's) code. First, if the code is that good it is usually readable and well commented, isn't it. And if it is not, well, here is where the questions will start. In any case, a fresh pair of eyes and a new perspective will already allow to discover wide variety of problems.

The issue of the personal abilities of the reviewer is so unimportant that I once thought of creating a tool called "semantic debugger". It would go over a code, compiler style, analyze it a little and ask you random questions like: "What is this variable for?", "When do you enter this function?", "Why is this exception unhandled?" and so on. I think the very fact that a programmer would have to think about answering those questions would by itself uncover a bug or two.

To conclude, the "code review" helps to find bugs, improves coding style consistency, allows less experienced programmers to learn from the more experienced ones and much more. A code review is definitely an important procedure one would want in a good software team, and possibly important enough to make Joel's list.

P.S. To the more theoretically minded, here is a link to an interesting work(.PDF) on how to estimate the number of problems that iterative code review allows to discover.