Pair programming, a technique for having two people together using one computer to develop code, is a method of programming that has come from the agile methodology of Extreme Programming (XP). I understand the concept, but admit to thinking it was a bit "extreme." I know I feel a bit possessive about my computer and even when someone takes over the keyboard to fix a problem, I get a little antsy. I want to have total control over what's happening. So how exactly does pair programming work and does it really improve the quality of the code?
How it works
As with most software development techniques, there are differences in how various teams implement the practice. Some organizations simply pair up individuals to work together, but don't expect them to share a computer. However, those who are practicing it in the true sense have one computer that is shared between a pair of developers. The two people work together to design, code and test user stories.
Pair programming is meant to be a partnership. It is not meant to be a method for training a new person. Ideally, the two people would be equally skilled and would each have equal time at the keyboard.
Working as a pair is a skill that doesn't always come easily. Learning to partner effectively in a team that close-- actually sharing a work computer-- is a skill that not everyone is comfortable with. Not only do you need to be a skilled programmer, you need to have the social skills of cooperation and the ability to partner with someone who may have a very different mindset than you have. Someone may be a brilliant programmer, but lack the social skills to be adept at pair programming.
How do partners split up the work? Perhaps one person will write the test cases using test-driven development techniques, and the other person will write the code to get the tests to pass. Perhaps they'll take turns in coding or reviewing. The idea is that they are working together, checking the work of the other so that there are always two sets of eyes on the code being produced.
Does it work?
Those who have perfected the technique are finding both quality and productivity improvements in their software applications. Mike Gehard from Pivotal Labs swears by it. The developers at Pivotal Labs work a very rigid work day, starting with breakfast, daily stand-ups, and then eight hours of dedicated pair programming. Programmers are told at the beginning of the week who they will be pairing with. The idea is to rotate, so you partner with different people.
What if two people don't get along? Gehard said that if two people partner very poorly, they don't pair again. However, they discourage people who partner well from becoming "sticky." They want people to learn how to partner well with everyone. This is such an important part of the culture at Pivotal Labs that the CEO of the company conducts the hiring interview with a pair programming exercise.
"It's not for everyone," Gehard admits. There are some people who don't like being "that close" to someone all day. People must be skilled at paired programming for it to work well.
Pair programming seems to be best suited for the types of applications where specialized skills, such as DBA skills, are not required. Again, the idea is that the pair of programmers is equally skilled, both contributing and acting as reviewers. Acting in this manner helps provide an added layer of quality that often is overlooked when only one developer is working on a piece of code.
As for productivity, developers are less like to surf the Web or become distracted by email or other tasks if they are working as a team. However, while code may be developed more quickly than if the same task is done by a single developer, organizations are paying for two developers. Thus, pair programming may produce higher quality results more quickly, but at a higher cost.
Tips for success
Cunningham & Cunningham hosts a wiki discussing the pros and cons of pair programming. In general, the attitude seems to be one which confirms that if done well, quality is improved and knowledge is spread among the team members.
Three tips that are recommended for success include:
- If the two partners are not of equal ability, have the partner with the lesser experience at the keyboard. This will help him learn and the stronger partner will learn from teaching.
- Have both partners involved in everything.
- Use test-driven development techniques, writing the tests before writing the code.
Pair programming is not for everyone. As with any effort, if the necessary skills are not present, there is not likely to be success. Pair programming involves both programming skills and social skills. Any two people working together on a project have the potential to be hugely successful if they work well as a pair or to be a disaster if they don't.
However, with the right people-- those who have the software development skills and enjoy sharing, learning and working together-- teams can benefits in quality, productivity and knowledge sharing from this approach. It might just be something worth trying in your organization.