Motivation: Improve Communication and Teamwork

There are many similar stories of teams who got started with pair programming. Before pair programming, they all walked into work in the morning at different times with a brown bag lunch in their hand. They walked into their office or cubicle and put their lunch down and their headphones on. They tapped on the keyboard all day. At some point, they took their lunch out of the brown bag and ate it. At the end of the day, they took off their headphones and headed home. They communicated with other team members mainly during meetings.

Post pair programming, these teams were completely revolutionized. Through pairing, the teams got to know each other better in a personal way, through some idle chitchat that goes on while pairing. A programmer might mention that they are going to a ball game or their child's recital that night. Then, the next day, whether they are pairing together or not, one might ask how the recital went or comment on the outcome of the game while they meet at the vending machine. As the team gets to know each other better, they are far more likely to talk with each other about both personal and technical matters. The communication barriers between each other start to crumble. Additionally, they feel better about their jobs because they know their teammates on a personal level.

We contend that communication is made more efficient in another important way. As we said earlier, Brooks considers training and intercommunication costs to be major cost factors. In discussing his law, Brooks asserts, "If each part of the task must be separately coordinated with each other part, the [communication] effort increases as n(n-1)/2" [Brooks1975]. It's easy to think about the items that need to be done to coordinate two interdependent parts dependencies need to be identified and scheduled accordingly, interfaces need to be specified, technical decisions might need to be jointly made, change management activities need to occur, and so on. Additionally, progress might be slowed if some critical coordination needs to occur when a team member is missing.

Let's think about how pair programming can make this communication more efficient. Consider first if a team does not rotate pairs but assigns larger pieces of functionality to static pairs. Then, instead of being broken into n parts, the project is broken into (n/2) parts and the communication effort increase is reduced from n(n 1)/2 to n(n/2 1)/4. When pairs work together, they decide on dependencies, technical aspects, and interfaces as they go. No separate coordination activities need to take place, and no dependencies and interfaces need special documentation, thus improving the efficiency of team communication. If pairs do rotate, and programmers partner with the programmer with whom their task is interdependent, we believe this intercommunication cost can be even further reduced.