Flylib.com

Books Software

 
 
 

Motivation: Reduce the Risk of Losing a Key Person


Motivation: Reduce the Risk of Losing a Key Person

With pair programming, the risk of losing key programmers is reduced because multiple people are familiar with each part of the system. If a pair works together consistently, two people are familiar with a particular area of the program. If the pairs rotate, many people can be familiar with each part. A common informal metric (invented by Jim Coplien of AT&T Bell Labs) is referred to as the "truck number." "How many or few people would have to be hit by a truck (or quit) before the project is incapacitated?" The worst answer is "one." Having knowledge dispersed across the team increases the truck number and project safety.

As programmers rotate among the group , they get the chance to know many on their team more personally . This familiarity breaks down many communication barriers. Team members find each other much more approachable. They struggle with questions or lack of information for less time before getting out of their chair and going to ask the right person a question—because they know that person quite well. Pair rotation enables person-to-person sharing of tacit knowledge, ideas, and insights that are not documented and are hard to articulate . Through pair programming, sharing of tacit knowledge takes place in the normal course of the programmers' day; no special resources, systems, or repositories need be allocated for this important knowledge sharing. Pair programming provides an organizationally supported vehicle for continual, ongoing conversations between programmers. Through these conversations, knowledge management takes place, along with a corresponding decrease in the risk of losing a key person on the team.


Motivation: Have Happier Employees

Turnover is very costly in both recruiting and training costs. Happier, less frustrated people are more positive about their job and are more eager to help the team meet its objectives.

More than half of programmers resist the transition to pair programming. However, once they try, almost all eventually favor the technique. The incorporation of pair programming has been shown to improve the engineers ' job satisfaction and overall confidence while attaining the quality and cycle time results discussed earlier. Pair programmers were surveyed six times on whether they enjoyed their job more when pair programming. First, an anonymous survey of professional pair programmers was conducted on the Internet. Both the summer and fall classes at the University of Utah were surveyed three times. Consistently, over 90% agreed that they enjoyed their job more when pair programming. The groups were also surveyed on whether working collaboratively made them feel more confident about their work. These results are even more positive, with 96% indicating that pair programming made them more confident.

Says Chuck Allison [Williams+2000]:

You know what I like about pair programming? First, it's something that has shown to help produce quality products. But, it's also something that you can easily add to your process that people actually want to do. It's a conceptually small thing to add… . And, when times get tough, you wouldn't likely forget to do pair programming or decide to drop it "just to get done." I just think the idea of working together is a winner.


Motivation: Reduce Training Time

In The Mythical Man-Month , Brooks states his law: "Adding manpower to a late software project makes it later" [Brooks1975]. He believes that communication costs are the major reason that adding manpower to a late project makes it later. Brooks breaks these communication costs into training and intercommunication. Certainly, reducing training costs is a worthy objective.

Traditionally, people new to an organization are shown different parts of a system by senior staff personnel. This dedicated training time costs the senior personnel valuable hours. During these hours, neither the new person nor the trainer is contributing to the completion of the project. Through pair programming, the trainer teaches by doing (not showing), and direct contributions are made during the training time. Additionally, training seems to go much faster, and the new person learns the system much better.