It’s safe to say that many of those who have decided to take the path of pair programming believe in it zealously. In a tip published over at SearchSoftwareQuality.com, Kim Barnes, a senior software engineer who got her first dose of pair programming at Oracle (then Sun Microsystems) in the early 2000s, strongly credits the practice for helping to produce better code, encourage learning, create better teachers and, overall, promote more team bonding.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But is pair programming all its chalked up to be?
For all the people on board with pair programming, there are still plenty who question the effectiveness of forcing programmers to work together. Take Jon Evans from TechCrunch, who cites evidence that people are, in fact, more creative and productive when working alone — whether it is coding or writing novels. However, he also presents evidence that suggests that while people may be more productive and creative when alone, working with others can help you think in ways you wouldn’t on your own.
As Evans points out, the best route is to find a careful balance between solo, pair and group programming. In fact, he describes one of his preferred team structures to be a situation where one person is the “primary” coder and the other is a “secondary” coder. They can program as pair at first, but later in the game the primary takes on most of the heavy programming while the secondary spends their time “sanity-checking the primary’s code and building bite-sized subsections.”
Pairs prevent problems
At the end of the day, however, it seems like pair programming has the vote of the people. Even developers who prefer to work alone have admitted that the benefits of pair programming are clear, as shown in this post from DZone. In it, Sam Atkinson, explains that companies should try to avoid the problem of the “10x developer” — a developer who knows and can build way more than anyone else on his team. The problem with this, he points out, is that if that 10x developer creates and maintains entire systems on their own, the other developers may not have any idea what to do with them if that developer decides to leave.
In the meantime, if you have a successful pair programming routines in place, Byron Sommardahl from Awkward Coder has ten effective suggestions for ways you can run that process into the ground.