Two brains better than one
Code reviews have long been cited as one of the most effective ways to remove
software defects. Study after study has come to the same conclusion. But
what is true in theory does not always work so well in real life.
In general, a code review involves a fairly structured process: You
publish the code and create listings, you invite carefully selected attendees,
you go through a defined meeting process with defined roles, and at the
end you have a series of recommendations for improving a piece of software.
There are a number of problems with this process. The biggest one is
this: We just don't do code reviews as often as we should. For those of
you working on large agency systems, when was the last time you had a code
review? What percentage of the code in your system has ever been reviewed?
And even when teams conduct reviews, a number of problems often arise.
In some cases, they invite the wrong people to take part. In others, they
do not follow through on the recommendations.
Also, teams sometimes review code only after the project is over or
when the code in question has been put into production. Obviously, the time
to have the review is when the code is fresh and being developed; that's
the time the programmer needs the most help. That's also the time when it's
easiest to fix problems.
There's a new software methodology afoot called extreme programming
that has an interesting idea about code reviews. If code reviews are a good
thing, why don't we do them all the time? Pair programming, an extreme programming
technique, helps make that happen, and it works remarkably well.
With pair programming, all the code in the system is written by pairs
of programmers working at a single workstation. That doesn't mean that
one programmer watches while the other one programs, however. It's an active
process: One person may be using the keyboard, but the other person is actively
involved, making suggestions, thinking about what has to be done next and
so on. The keyboard switches hands frequently.
Pairs are not fixed; you can pair with one person in the morning and
another in the afternoon, depending on what you need to accomplish.
Data seems to indicate that it costs about 15 percent more to do programming
this way not the 100 percent you might expect. That's partly because there
are fewer false starts and less debugging during development. (It might
also be because it's more fun, and the programmers produce more.)
The real payoff, though, is in defect reduction and hitting deadlines.
Code produced this way has a much lower error rate than code produced the
older, individual way. Pick any average cost per defect that you're comfortable
with (some people use $8,000 per defect), and an extra 15 percent in the
development budget can clearly be justified.
The next time you get a chance, give pair programming a try. You might
be surprised how fast and how well the system gets built!
Bragg is an independent consultant and systems architect with extensive
experience in the federal market. He welcomes your questions and topic suggestions