Code Inspection Through Pair Programming Practices
Software inspections are usually seen as a review technique to eliminate defects. The truth is they don’t work anymore. One is left with two choices: Changing the code review process or changing the goals from removing defects to something that could be more effective. Or you could combine the two and come up with a solution.
You could use pair programming approach and use a more flexible testing process as Matthew Heusser suggests on cio.com. The classic objection to pair programming is cost, as having two people do one job is something people have misgivings about. Academic research shows that projects done with pair programming don’t actually cost twice as much. Mary Poppendeick, co-author of three books on lean software development, recommends pairing an expert performer with a new performer; this serves as cost-effective, on-the-job training. Poppendeick cites the effective use of this approach in several industries.
Two chief methods of doing pair programming have emerged of which the first is to have a driver/navigator combination. Here one person has his/her hands on the keyboard, tactically analyzing the current statement, while the observer takes a higher-order view of the code and the changes to the design over time. The other is the ping pong approach. With ping-pong, one partner writes a test, and the other person takes the keyboard and implements the code to pass that test. This method necessitates two keyboards, mice and identical monitors connected to one computer.
However this technique has tradeoffs as well. Testers are a group of workers who may benefit from inspections but they may not be willing to participate in pair programming. Some may find this technique distasteful as it is a social process. Chris McMahon, a QA lead at the Wikipedia Foundation, claims that, an organization may accept third party contributions, or contract/outsource work, and still want to do some form of inspection or audit before adding the code to the build. McMahon states that some distributed teams find remote pair programming impractical, even though there have been great improvements in screen-sharing tools over the years.
“If you do traditional inspections; make them light, easy and quick”, advices James Wang, vice president of peer review products for SmartBear Software. “The process should be as easy as finding a changeset (or a few) and clicking a button to request a review. This should send a notification to qualified reviewers who can see one set of differences, mark up the differences with notes and send it back," Wang states, noting that collecting audit material should also happen with the click of a button. "If you don't have things like that in place, it will be very hard for your review process to be successful."
Heusser observes that continuous pair programming would be best for code review. His advice: Although your organization may have serious functional, cultural and technological objections to pair programming, the benefits will outweigh the up-front costs as well as the learning curve associated with pair programming.
Post your Comment
All form fields are required.