A Study in Pair Programming

Eric Schwartz
Dec 22, 2016 · 4 min read

One of the best aspects of my first few weeks at Flatiron School has been the opportunity to work closely with so many talented, ambitious students. Before the course started, I held the common preconception that coding was a solitary endeavor.

I have since seen the benefits of coding in pairs (and even in groups of three or more!)

Personally, I find it to be more enjoyable than working alone. Plus, the work gets done faster, and I always learn from whomever I happen to work with. That said, not everyone in the class seems to have had the same experience. Some find that they work best when they put on their headphones and go to their own space. Also, in the professional world, I could see why managers might not want to have two of their paid employees working on one program.

A quick Google search showed me that I am not the first programmer to ponder the costs vs. benefits of pair programming. I have parsed through some of the more extensive studies that I came across and formed my own conclusion on the subject.


Pairing in a Learning Environment

It seems the general consensus would agree that pair programming provides a huge advantage when it comes to learning to the learning process. For one, it requires both students to stay focused and fully understand every aspect of the code. In addition, there is always something to be learned from a fellow programmer at any level. We all come from different backgrounds and have different skill sets, so it is inevitable that we’ll be able to show off some new trick, or on a broader scale, a different perspective to solving a particular problem. And if that’s not enough, it trains us to become better communicators of a subject that is notoriously difficult to communicate. We’re becoming eloquent tech-talkers.


Pairing in a Professional Environment

This is where the study gets interesting. When we are in learning mode, we aren’t working on real projects with deadlines, and we aren’t being paid salaries. We don’t have to worry about the same factors that a business owner or manager needs to consider.

Economics

Let’s start with an economic analysis. At a glance, it seems that pair programming would take 100% more man-hours for a project because you’d have two people working on the same one program. But, considering the increase in speed resulting from two brains working together, that figure usually looks more like 15%. Great, but it means that even though the projects are being finished faster, it is still less efficient than working individually… or so it seems.

When a program is written by a pair, the quality of the code is usually significantly higher. Pairing often forces the two programmers to discuss the best methods for any given situation and results in superior code. The code ends up being easier to read and more abstract, enabling smoother additions and edits in the future. Does this make up for the 15% increase in working hours? Maybe so maybe not… but there is another aspect to look at.

Industry data shows that pair programming results in an average of 15% fewer defects. Note that the average defect takes 7–8 hours to resolve and consider that a project could have hundreds of defects. Eliminating 15% of the defect-resolving time means very large decreases in man-hours, vastly outweighing the extra man-hours required for pair programming. In other words, a company can save lots of money by having their developers work in pairs.

Satisfaction

An online survey showed that 96% of programmers preferred working in pairs to working alone, and 95% of them felt more confident in the code they wrote. With someone constantly reviewing your work, you can rest assured that you haven’t made any major mistakes.

Results of anonymous surveys of professional pair programmers and of student pair programmers at the University of Utah

Pair programming also promotes team-building and communication between coworkers. These are universally important characteristics for any company. It means that more people will understand the code being written, and it simply means that more friends will be made. My cohort recently had a communication workshop led by Andrew Tarvin, (also affectionately known as “the ‘bunny bunny’ guy”). Andrew told us that people who have at least three close friends at the workplace are 95% more likely to be satisfied with their lives. We know that a satisfied team will be more productive and employees will be less likely to jump ship.


Conclusion

Ultimately, developers each work in their own way and should figure out what works for themselves. But based on both personal experience and extensive research on the topic, the benefits of pair programming seem to significantly outweigh the costs.

Pair programming ftw!

Sources / Further Reading

https://en.wikipedia.org/wiki/Pair_programming

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

https://blog.codinghorror.com/pair-programming-vs-code-reviews/

Eric Schwartz

Written by

Full stack web developer with experience in JavaScript, React/Redux, and Ruby on Rails. Musician turned coder.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade