Everyone agrees that code review is good for you. We are tracking both how many code reviews were done, and how many bugs we’ve uncovered during the sessions.

We’ve been at it since Dec-06, and in April I did a summary to see where we are. The more reviews we do, the more bugs are discovered – no surprise there. The summary makes a compelling argument on why there should be more code reviews. In March, for instance, out of 17 sessions, we found 13 bugs. That’s a good percentage, I think. So that would be a great way to convey the message: Do more, it helps.

And then something comes up. It seems that a refactoring we did in one of the bug reviews, introduced a bug. (This would be a good place to point this is VB6 code – so refactoring is done by hand, and no automated tests to run).

So the discussion now is what to do in order to prevent this. At the situation, the programmer sat with 2 people (me included), and made the changes with us. Since both of the reviewers do not the code (which is one of the goals of code reviews), we couldn’t identify the problem. Actually, code reviews are the way to prevent this. With more code reviews, teammates can identify this. But I digress.

I’m willing to accept one bug introduction over 30 found. I think it’s worth the risk. And it’s not like changing code in a code review is different than changing code at other times. The risk is still there. However, the discussion continues.

I find it irritating when people don’t focus on the important stuff, and rather enjoy a lively debate on side effects.