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?
Introversion actually has little to do with the notion that people like solo work. Have a look at the MBTI’s of the people on Ward Cunningham’s C2 wiki:
Some of the originators of XP such as Ron Jeffries, and early adopters such as Dale Emery & Josh Kerievsky are introverts, and they invented and refined the pairing concept. So, being an introvert isn’t a reason not to pair.
You can also introduce pairing by having the whole team try it for 2-3 iterations. In my experience that has more “sticking power” than making it purely voluntary. After that length of time people will have had a chance to see where it works and where it doesn’t in their context.
I fully advocate pairing beyond just programmer to programmer. There is tremendous value in doing that, and almost everyone in the business has done it at some point in time.
Finally, when training teams I don’t simply say “Do Pair Programming”. I step up a level and look at the overall goal, which is to have tactical (and some strategic) design decisions made a close as possible to implementation and with multiple people making them. Additionally, basic code inspection is a cheap way of catching defects before they reach production code. Finally, there needs to be a spread of information across the whole team in order to foster true cross-functionality.
You can achieve those goals in multiple ways. In my experience over the past decade, pairing is by far the best.
Comments are closed.