Pair Programming

One of the best practice in extreme programming (XP) is Pair programming. The concept is simple: “Two are better than one” so by having two developers actively building code will result in better quality software. With XP, all code must be done by pair programming. However, it is not one person coding and another just watching but both take turn to code several times each day. When one person code, the other is thinking about how to test it and how to integrate the code to previously released software to ensure maximum quality and minimum defects.

After working together as a pair for few days, developers must switch with another pair so they have a chance to work on different functions of the software. As they are moving to different pair, they have to learn new things, eventually they will understand the entire system rather than just few functions. Having developers working on every part of the system will also expose any hidden problem so it can be fixed quickly and efficiently. Working in pair forces developers to write better code, to be more careful on what they do (Because someone is watching), to follow standard process (Your partner is also working as SQA) and eventually developers will learn about working as ateam. The project can benefit from less depending on few key developers and the works would be spread more evenly among team members.

However, many project managers do NOT like pair programming. They believe that having two developers sit next to each other is a waste of time. When I teach XP to project managers, I always explain the benefit of pair programming as performing continuous code review. Without it, project will need to have additional code inspections, additional SQA process compliance review, and additional formal reviews. All of these activities will add more time, more efforts and more costs to the project. Pairing also lets project managers find out quickly who is good and who will need additional trainings, who has better performance and high productivity and who will always be a problem for the team.

Many developers do NOT like pair programming because it can expose some of their weakness to others. They believe that pair programming can create personal conflict. When I teach XP to developers, I always explain the benefit of pair programming as a good way to teach new employees. If you let these inexperienced developers alone to do works, they will suffer as they have to learn many things in a short time. By pairing them with a more experienced developers, they can observe and learn much faster. The more time they work in pair, the more they learn and contribute.

To ensure XP implementation correctly, company must have a XP coach to guide people in the right directions. Software development is a team effort and every team must have a coach (i.e., Scrum has Scrum master and soccer team has coach). The coach must be someone who had proper XP training and experienced with XP projects so he can monitor the pair programming activities, making sure the XP technique is executed correctly, and fixing problems before software is released to the customers.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University