Code Reviews
For many types of work it is standard practice to have one's work checked by another before the work product is put into service. Authors have editors; engineers have inspectors and so on. But in software development it is common for code to flow directly from the programmer's fingertips into the hands of the end users without ever having been seen by another pair of eyes.
This is despite there being a large body of empirical evidence establishing the effectiveness of code review techniques as a device for defect prevention. Since the early history of programming, a number of
different techniques for reviewing code have been identified and assessed. A code walkthrough is any meeting in which two or more developers review a body of code for errors. A code walkthrough can find anywhere between 30 and 70 percent of the errors in a program1. Code reading is a more formal process in which printed copies of a body of code are distributed to two or more reviewers for independent review. Code reading has been found to detect about twice as many defects as testing2. Most formal of all is the code inspection, which is like a code walkthrough where participants play pre-defined roles such as moderator, scribe or
reviewer. Participants receive training prior to the inspection. Code
inspections are extremely effective, having been found to detect between 60 and 90 percent of defects3. Defect prevention leads to measurably shorter project schedules. For instance, code inspections have been found to give schedule savings of between 10 and 30 percent.
I estimate that about 25 percent of the projects I have worked on conducted code reviews, even though 100 percent of them were working against tight schedules. If we can save time and improve quality with code reviews, why weren't the other 75 percent of projects doing them?
I believe the answer is mostly psychological, and the basic mechanism is the same one that I engage in every time I go on one of my unplanned excursions in my car. The essential problems are short-term thinking, force of habit and hubris.
Suppose you have just finished coding a unit of work and are about to check it into your project's version control system. You're faced with a decision – should you have your code subjected to some review procedure, or should you just carry on to the next task? Thinking about just the next five minutes, which option is easier? On the one hand you'll have to organize the review, put up with criticism from the reviewers, and probably make modifications to your code based upon their responses. On the other hand, you can declare the task "finished', get the feeling of accomplishment that comes along with that, and be an apparent step closer to achieving your deadlines. So you make the decision which minimizes discomfort in the short term, the same way I decide to just keep on driving in search of a road sign rather than pull over and consult my street directory.
But then, you've got to rationalize this laziness to yourself in some way. So you reflect on previous experience and think "I've gotten away with not having my code reviewed in the past, so I'll almost certainly get away with it again". Similarly, I'm driving along thinking "I've never failed to
eventually get where I'm going in the past, so I'll almost certainly get there this time as well." Complacency breeds complacency.
Finally, although it is difficult to admit, there is some comfort in not having your code reviewed by others. We would like to think that we can write good code all by ourselves, without the help of others, so avoiding code reviews enables us to avoid confronting our own weaknesses. In the same way, by following my nose rather than following my street directory, I can avoid having to confront the geographically exact evidence of my hopeless sense of direction that it will provide. Ignorance is bliss.
Even when you quote the empirical evidence to programmers, many will still find a way to excuse themselves from performing code reviews, by assuming that the touted reductions in schedule and improvements in quality were derived through experimentation upon lesser developers than themselves. The thinking goes something like "Sure, code reviews might catch a large percentage of the defects in the average programmer's work, but I'm way above average, don't write as many defects, and so won't get the same return on investment that others might." Unfortunately it is very difficult to tell simply by introspection whether you really are an above average programmer, or whether you just think you are. Most people consider that they are "above average" in ability with respect to a given skill, even though they have little or no evidence to support that view. For example, most of us consider ourselves "better than average drivers". The effect is sometimes referred to as self-serving bias or simply the above
average effect.
Those that have bought into the Agile propaganda (can we call it "agile- prop"?) may have been deceived into thinking that pair programming is a substitute for code reviews. To the best of my knowledge, there is no credible empirical evidence that this is the case. In fact, there are good reasons to be highly skeptical of any such assertions – in particular, that a pair programmer does not have the independent view of the code that a reviewer uninvolved with its production can have. Much of the benefit of reviews comes from the reviewers different psychological perspective on the product under review, the fact that they have no ego investment in it, and that they have not gone through the same (potentially erroneous) thought processes that the original author/s have done in writing it. A pair programmer is not so divorced from the work product or the process by which it was generated, and so one would expect a corresponding decrease in ability to detect faults.
So we sustain self-defeating work practices the same way we sustain many other sorts of self-defeating behavior – by lying to ourselves and putting long term considerations aside.