Pragmatic Pair Programming

Posted by on Jan 9, 2011 in Software Development | 2 Comments

Pair programming is all the rage these days and for good reason. You get well-tested, well-thought-through code at a dizzying rate without many of the pitfalls of solo programming. Pivotal Labs have been pioneers in this area, showing the industry how it should be done in practice.

The downsides of solo programming are many. It’s far too easy to:

  • get hung up for hours on a trivial problem
  • write code that’s inconsistent with the rest of the system
  • skip writing a unit test here and there
  • take shortcuts you’d be too embarrassed to take in front of someone else
  • rack up technical debt
  • lose motivation

You won’t find pair programmers gazing out the window, surfing Facebook, IM’ing, or shopping on Amazon. They’re focused and pushing each other to write great software. I’ll hire pair programmers over 2 solo programmers any day of the week. The long-term costs of owning and maintaining pair programmed systems are far less than a system developed by a team of solo programmers.

That said, the notion that you should pair on every line of code while sharing one computer is like charging your clients for a backhoe loader with operators when sometimes they only need a guy with a shovel. Wikipedia references pair programming studies that have shown pairing on complex problems yields better quality code with fewer defects in the same number or fewer total developer hours. Right on! If you’ve paired you’ve experienced the magic. But wait, with simpler problems the studies showed pairing yielded the same quality code in double the number of developer hours. Makes sense too, right? Pairing through the simple stuff can be a bit tedious.

Pragmatic pair programming is all about pairing on the complex stuff and then when you hit some easier stuff, parallelizing and soloing on it. For example:

Now that we have the acceptance tests and controller tests in place you work on the validations while I work on the JSON serialization. Then lets come come back together to pair on the business logic.

You still sit together and work together but now you’re working optimally pairing on the complex and parallelizing on the simple. Give it a shot and let me know how it works for you!


  1. Stewart Gleadow
    October 21, 2011

    I really like the approach to efficient pair programming here. I use a similar approach.

    One concern I have is that if you haven’t spend a significant amount of time pair programming, it’s hard to know when to divide and conquer and when to pair. From what I’ve seen, people that haven’t paired a lot before will nearly always opt for the divide and conquer for any class of problem, so you’re essentially not pairing at all.

  2. Christopher Pickslay
    October 21, 2011

    That’s a great point, Stewart. I’ve seen the same thing happen. One thing we try to do whenever we can is to pair people inexperienced in pairing with people who have done a lot of pairing. Generally the person who’s more experienced will lead those decisions and lean more toward pairing than dividing, if for nothing more than to help the other programmer get the hang of it.

    But it doesn’t always work, and some programmers will go out of their way to avoid pairing whenever they can. We’ve made the decision that it’s an important part of our culture, so we now seek out people who are personally motivated to pair program and who thrive on the process.


Leave a Reply