The agile development practice of “pair programming” endorsed by advocates of eXtreme Programming (XP) is controversial. On the surface, it seems that having two programmers work side-by-side sharing a keyboard will cut productivity in half. (It surely will if you take this to the limit and stuff two programmers in every cubicle. But at least you’ll need less office space and fewer computers, right?)
The counter-argument is that the quality of the code will improve resulting in fewer defects and less time spent fixing them. In addition, communication and knowledge-sharing will improve. Less rework and less refactoring should improve long-term productivity even if there is a short-term reduction.
Perhaps the larger problem is that some software developers simply don’t like pair programming. Think about it. Many developers are introverts. They like solo activities. They take pride in their work and seek peer recognition for it. Let’s find a middle ground. You don’t have to fully adopt pair programming to practice XP or any other form of agile development.
Pair programming can be a tough sell.
You may find that some of your developers like it and some don’t. That’s okay. It doesn’t have to be an all or nothing approach. Encourage those that want to pair-program to do so. Let those that don’t continue to operate solo. They may change their minds once they see how others benefit.
Try using pair programming in special situations where there is an easy sell. For example:
- It’s a great way to train new hires. They get to sit with an expert team member, learn, ask questions and dig into the code.
- It helps when implementing new technologies. The developers can help each other to understand the environment and accelerate learning for both of them.
- It’s a good way to begin development using a new custom design or a design pattern. They can jointly dig into the new system and help each other understand it.
- It may help with portions of the code that are high risk, poorly understood or (execution) time-critical. This is the “two heads are better than one” principle.
These are situations where pair programming can be used for a brief period of time to solve a problem. Some developers may grow to like the approach and want to continue using it. Others will want to go it alone.
When using pair programming, it’s a good idea to mix up the pairs from time to time. This improves cross-training and knowledge-sharing. Also, pair programming does not have to be used all day, every day. Allow the developers some flexibility to determine what works for them.
One more approach is worth considering.
There is one more variation on the pair programming approach that’s worth considering. Try having a software engineer and a test engineer work side by side. One can write the base code while the other writes the test cases. This should be more reliable than having the software engineer write both the code and the tests.
Admittedly, this is not strictly pair programming because the engineers are not working on the same code elements; they are working on related elements — but it’s still worth a try.
If you are not doing pair programming, I hope you employ design and code reviews as ways of improving software quality — because developer isolation is not a critical success factor. What do you think?