BrainBrain View Note

After several e-mail exchanges with Eda-qa about pair programming, here are my own conclusions. I found the discussion helpful as far as clarifying my own interpretation of the experiences I've had with pair programming.

- On an elite team, full time pair-programming may not be a good idea. Pairing may reduce the productivity of individual team members without any offsetting benefit. Team members should however check into the repository incrementally and make their work available for others to look at. Informal discussions and reviews may be good enough to keep the rest of the team abreast of the new code being developed. If a team member starts having problems, he or she should ask for help, and ad-hoc pairing is one good approach in this case.

- Full time pairing on a team smaller than 4 may be counter-productive. Ad-hoc pairing may be a better choice in such circumstances. If you have 3 developers, obviously someone will always be left out at any given point in time. With two developers, their communication channels should be clear enough that they may want to work separately in order to get more done. It's well known that communication becomes much more difficult as the number of people increases. Let's assume you want a communication channel between every pair of people in a group. With two people, you only need 1 communication channel between them. With three, you need three. With 5 you already need 10 channels and for 10 people you'll need 45. I'm not saying every developer absolutely needs to communicate with every other developer, but I just want to illustrate that communication does become a problem as team sizes increase. Therefore the value of pair programming as a way of keeping people in sync increases as the total size of a development team increases. By the way, the formula to calculate these numbers is n choose m (the binomial coefficient) where in our case m is always set to 2 as n grows. n choose 2 can be simplified to n(n-1)/2. The complexity of this function is in O(n^2).

- Pair programming is most beneficial for the first 3-6 months of a project when the core foundation for the code is being developed. Once development becomes more routine and best-practices have become a habit on the team, maybe pair programming discipline can be relaxed. Of course if the team finds that quality begins to suffer once they stop pairing, they should get back into it.

- It's important to recognize that any practice can degenerate if the developers involved don't really understand why they are doing what they're doing. Pair programming is no different. It should help focus developers on learning from each other and improving quality, but the practice alone doesn't offer any guarantee of that. If your pair is spending the time away from the keyboard sleeping, that's not good!

- On a typical team (somewhat below to somewhat above average), pair programming can be valuable along a number of dimensions: - pair programming percolates lessons learned from mentors/leads throughout the rest of the team (the person who last paired with the mentor passes on this knowledge to his/her next pair, and so on). I have not seen a more efficient way to spread knowledge and good habits throughout a team.

- pair programming improves whole-team productivity by promoting a common set of best-practices (focus on discipline and quality) and broad understanding of the code base by the entire team. It's true that if you have a very productive developer, that person's productivity might actually slow down when working with a less skilled pair, but over time, that less skilled partner will learn a great deal and improve his or her productivity significantly. The overall productivity of the team will thus generally improve, since such elite developers are very rare.

- An increased focus on quality should mean that the team as a whole produces fewer bugs and therefore can concentrate on new features. Since most of the teams I've worked with have been significantly hampered by bugs, I think this is an important way in which pair programming, along with other XP practices, can improve the productivity of the team over all.

- Since pair programming spreads knowledge throughout a team, it also greatly reduces the risk involved in making one developer responsible for much of the critical work on a project.