by Chris Erin on December 6, 2016

Pair programming reduces the amount of defects in a system.

At Hashrocket we pair. We pair by default, which means 80% of the time we pair 100% of the time. It works great for us, but have you heard anybody espouse the productivity gains of pair programming recently? There's not much on the internet about pair programming and what there is always attaches an adjective to pairing like, "controversial" or "extreme". But at Hashrocket its not controversial, its not extreme, its productive. It's productive because the design of the software gets better -- significantly -- and the number of bugs go down -- significantly.

When a bug is discovered by a customer a range of things can occur. In the best case, the bug is reported by the user, which takes time and patience from both the user and the organization to deal with effectively. In the worst case, the user stops using the software, the bug is not reported, and this gets repeated as more users encounter the bug. Bugs range from moderately expensive to very expensive, but in all cases a bug encountered by a user are much more expensive than bugs encountered and fixed before they reach production.

Pairing is entirely counter intuitive. Its hard for a product manager to realize the many smaller design challenges in every feature or even the trade-offs among the bigger design challenges. Without those its hard to accept that a feature will take roughly the same amount of time to build but will cost twice as much. If there were an imaginary defect count that could be reduced by investing in the software it would be straight forward, but the expectation in both non-pairing and pairing situations is that every developer create defect free software. That's unrealistic.

Defects are inherent in all software and even the biggest companies with the biggest budgets create amazing, head-scratching, dumb-founding bugs. We've learned to tolerate it. When an application unexpectedly closes, well, we just re-open it! So if the biggest companies with the deepest pockets have issues with quality, can you expect an ordinary developer with ordinary skills to create extraordinary work? Programming is a profession with big talent differences across all its practitioners, but rarely do the most talented think through all edge cases and even more rarely do they resist the myriad of web-based, human-based, work-based and life-based distractions that mass on the edge of every quiet, creative moment.

Pair Programming reduces distraction based defects because a pair is always insistent that focus be given to the task at hand. Its easier to follow software best practices when there is an ongoing discussion of best practices between the pair. When a design choice is necessary, there are many more options and an even discussion of pros and cons for each because that's a natural thing to do. Every code change must be packaged nicely and wrapped with a bow, when has anybody ever wanted another persons sloppiness to be reflective of them? When pairing, the right thing must be done and the right questions asked. And above all its progress. Evenly-paced consistent progress.

There are many advantages to pairing and I only touched on some of them. It takes the right people and a number of cultural and structural elements to make it work. The developers at Hashrocket like to pair and know how to work well together, and we have the code quality to prove it.