Using Pair Programming Practices in Code Inspections
If the dynamics of code inspections have changed in the past three decades, how should we inspect now? Matt Heusser suggests that pair programming principles could provide some, but not all, of the answers.
Wed, May 09, 2012
CIO — Software inspections are traditionally described as a review technique intended to eliminate defects, but in reality they don't work. At least, they don't work now for the kind of projects most software teams work on.
This leaves us with two options: Radically change the code review process or change goals and expectations from defect removal to something more effective. Ultimately, both options may be part of the answer—that is, considering a pair programming approach and adopting a more flexible testing process.
A Start: Radically Changing the Inspection Process
A literature review suggests that the earlier a bug is discovered, the cheaper it is to fix. If that is true, then we should not be inspecting the code after it is complete, but, instead, should perform the review during the programming cycle, in the moment.
This kind of cranking the dial to 11 on peer review has a name—pair programming. A core practice of extreme programming, which was introduced in 1999 by Kent Beck and Ward Cunningham, pair programming is now considered a standard Agile practice, although perhaps not a standard software practice. The classic objection to pair programming is cost, as having two people do one job is something some people find questionable. But does pair programming actually cost more?
Academic research doesn't support that objection, in the sense that projects done with pair programming do not cost twice as much. In 2000, Laurie Williams, a professor of computer science at the University of Utah, co-authored a paper with Alistair Cockburn evaluating the cost/benefit ratio of pair programming. Williams and Cockburn used pair programming in classes. On the first assignment, total time spent by the pair was roughly twice that of one person. The big win, however, was on the second and subsequent assignments, when the total time dropped to about 20 percent more than having an individual do the assignment, even while counting two people on one computer for one hour as two hours.
Beyond the obvious benefits in decreased linear time, or time to market, and modest cost increases, Williams and Cockburn found the code produced was generally more correct and passed up to 15 percent more test cases when compared to code programmed by an individual. (Think of a "test case" as the kind of test a professor would run on the code to determine a grade.)
The final benefit of the case study was fewer lines of code, or more compact code. This makes code easier to change in the future.