Better Software - July/August 2008 - (Page 47) The Last Word Encourage Pair Programming by Rob Myers After a decade in the public eye, pair programming is still one of the most controversial of all agile practices. Appropriately, managers are concerned about the costs and developers are concerned about personal agony. I would like to enumerate some of the subtle—yet highdividend—benefits of this discipline. sense to) that one programmer activities. Each person knows that the other is One great way at that point in time. Many of us have been forced to look waiting. at code that we wrote mere Since break boundto enhance months earlier, and we scratch aries are clear, people our heads in confusion. will use the break to its Code written by two is readgreatest benefit. A short, your understanding able by—and makes sense to— restful break often is all many. Understandable code that is needed to “step leads to better maintainability away” from a tough en- of a topic is to teach and changeability. The softgineering problem and ware is more easily extended can lead to spontaneous someone else from your later for better profitability. breakthroughs. Team-building: Pair proFewer Interruptions: gramming fosters a collaboraPeople prefer not to interexperience. tive atmosphere. Real teamrupt a pair. Programmers function brilliantly when work gets more work done, they are “in the zone,” and interruptions and people naturally stop viewing their cause them to snap out of it for up to teammates as competitors for scarce rehalf an hour. This can get costly. sources (e.g., bonus money). The natural If you decide that it’s worth the time competitive spirit becomes externally to interrupt, you will likely find that focused, and the team knows that it has only one of the pair is needed to provide a key role to play in beating the organiyou with the assistance or information zation’s competition. There is less stress you require. Only one person leaves “the because there is less energy wasted figzone.” The other person is listening but uring out how to maneuver politically is still capable of rapidly bringing the within the organization. pair back on task. Cross-Training: Intellectual crossFewer Defects: It’s like a continuous pollination occurs bidirectionally. A code review. Pair programming would good amount of interesting and useful find most of the same defects as a thor- training occurs on the job, without ough code review, but pairing is far any loss of productivity. Much of that easier to schedule and finds bugs before training is about the overall design and they set up residence in your code repos- architecture of the product. itory. The longer a bug resides in your New teammates assimilate culture code, the greater the chance that another and become productive immediately. The developer—or a customer!—will start to team can be scaled, gradually, and with rely on the bug’s existence. less disruption. The new hire notices her In practice, a bug is much easier to own contributions immediately. spot by a pair of programmers at the Seasoned teammates learn a lot, too, time it’s written, because the navigator by working with people who have difkeeps the larger design context in mind ferent backgrounds and technical exand the driver is freed up to keep more periences, and by confidently exploring of the detailed context in mind. Those together the latest technologies and how mental states are difficult to achieve even they may fit into the product. a day later in the code review meeting. One great way to enhance your Maintainable Code: Code is more understanding of a topic is to teach readable. Code written by one pro- someone else from your experience. This grammer is readable by (i.e., makes continuous learning provides the team What Is Pair Programming? Briefly, pair programming is two people working together at one computer on one programming task. One person is the “driver” (with keyboard and mouse) and the other is the “navigator.” I’ll acknowledge that this leaves out a large number of details (e.g., physical arrangement of furniture and monitor, how often we switch roles, how often we switch people, matters of etiquette, and so on), but this definition will work for the scope of this article. Is It Wasteful? In my experience, the teams that are building the most valuable software the fastest are combining the best ideas and practices from Scrum, Extreme Programming, and lean, and everything they try, they try wholeheartedly. They experience various costs; some are additional, some were hidden by other approaches. But they also experience great gains that outweigh the costs. Though it may appear to be “two doing the work of one,” pair programming is best seen as essential collaboration. When we look at pairing from a lean perspective, we see that the benefits to the whole value stream outweigh the costs. Discouraging pair programming is a “local optimization” that prevents us from “optimizing the whole.” So, What Are the Benefits? Valuable Breaks: Pairing encourages brief, useful breaks. Since pairs negotiate timeboxed breaks, people are less likely to meander into longer break-related www.StickyMinds.com JULY/AUGUST 2008 BETTER SOFTWARE 47 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.