Code reviews have long been cited as one of the most effective ways to remove software defects. But what is true in theory does not always work so well in real life.
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 at firstname.lastname@example.org.
NEXT STORY: Making GPRA 'part of the culture'