21.2. Pair Programming

 < Free Open Study > 

When pair programming, one programmer types in code at the keyboard and the other programmer watches for mistakes and thinks strategically about whether the code is being written correctly and whether the right code is being written. Pair programming was originally popularized by Extreme Programming (Beck 2000), but it is now being used more widely (Williams and Kessler 2002).

Keys to Success with Pair Programming

The basic concept of pair programming is simple, but its use nonetheless benefits from a few guidelines:

Support pair programming with coding standards Pair programming will not be effective if the two people in the pair spend their time arguing about coding style. Try to standardize what Chapter 5, "Design in Construction," refers to as the "accidental attributes" of programming so that the programmers can focus on the "essential" task at hand.

Don't let pair programming turn into watching The person without the keyboard should be an active participant in the programming. That person is analyzing the code, thinking ahead to what will be coded next, evaluating the design, and planning how to test the code.

Don't force pair programming of the easy stuff One group that used pair programming for the most complicated code found it more expedient to do detailed design at the whiteboard for 15 minutes and then to program solo (Manzo 2002). Most organizations that have tried pair programming eventually settle into using pairs for part of their work but not all of it (Boehm and Turner 2004).

Rotate pairs and work assignments regularly In pair programming, as with other collaborative development practices, benefit arises from different programmers learning different parts of the system. Rotate pair assignments regularly to encourage cross-pollination some experts recommend changing pairs as often as daily (Reifer 2002).

Encourage pairs to match each other's pace One partner going too fast limits the benefit of having the other partner. The faster partner needs to slow down, or the pair should be broken up and reconfigured with different partners.

Make sure both partners can see the monitor Even seemingly mundane issues like being able to see the monitor and using fonts that are too small can cause problems.

Don't force people who don't like each other to pair Sometimes personality conflicts prevent people from pairing effectively. It's pointless to force people who don't get along to pair, so be sensitive to personality matches (Beck 2000, Reifer 2002).

Avoid pairing all newbies Pair programming works best when at least one of the partners has paired before (Larman 2004).

Assign a team leader If your whole team wants to do 100 percent of its programming in pairs, you'll still need to assign one person to coordinate work assignments, be held accountable for results, and act as the point of contact for people outside the project.

Benefits of Pair Programming

Pair programming produces numerous benefits:

  • It holds up better under stress than solo development. Pairs encourage each other to keep code quality high even when there's pressure to write quick and dirty code.

  • It improves code quality. The readability and understandability of the code tends to rise to the level of the best programmer on the team.

  • It shortens schedules. Pairs tend to write code faster and with fewer errors. The project team spends less time at the end of the project correcting defects.

  • It produces all the other general benefits of collaborative construction, including disseminating corporate culture, mentoring junior programmers, and fostering collective ownership.

cc2e.com/2192

Checklist: Effective Pair Programming

  • Do you have a coding standard so that pair programmers stay focused on programming rather than on philosophical coding-style discussions?

  • Are both partners participating actively?

  • Are you avoiding pair programming everything and, instead, selecting the assignments that will really benefit from pair programming?

  • Are you rotating pair assignments and work assignments regularly?

  • Are the pairs well matched in terms of pace and personality?

  • Is there a team leader to act as the focal point for management and other people outside the project?


 < Free Open Study > 


Code Complete
Code Complete: A Practical Handbook of Software Construction, Second Edition
ISBN: 0735619670
EAN: 2147483647
Year: 2003
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net