Mischiefblog
I make apps for other people

In defense of Pair Programming

Posted by Chris Jones
On March 18th, 2012 at 08:42

Permalink | Trackback | Links In |

Comments Off on In defense of Pair Programming
Posted in Tech, Work

A TechCrunch opinion piece posted yesterday, “Pair Programming Considered Extremely Beneficial,” was very complimentary about Pair Programming, a practice in which two developers work together to build software, one driving (typing) and the other navigating (describing what needs to be done). The author even included an amusing anecdote about Guy Steele pairing with Richard Stallman and how intense that experience was.

Since starting work at Overstock in 2010, I’ve had the opportunity to pair on a lot of user stories. Depending on the team lead pairing was either more or less the norm (less on my current team) but the company does have an inviolable rule when pairing must take place: when you’re working on financially impacting code. I’d extend that to say that you should pair on anything that impacts your core business and could cause the company to lose or have to restate revenue.

One point missed in the opinion piece was the discovery that Pair Programming reduces the defect rate of software, a number bandied around the Salt Lake City Software Symposium in 2011 was a reduction in defects of up to 80%. Even a 5-15% reduction in defects will pay for itself as pairing imposes an approximately 15% increase in development costs. Studies have consistently shown decreases in defect density with pairing (i.e., Pair Programming and Software Defects – an Industrial Case Study). Considering the potential cost of a defect in a production system and the time and expense of analyzing, testing, and (in non-Continuous Deployment environments) deploying the fix, a 15% up-front increase in development cost may be worthwhile.

The comments on the opinion piece raised my hackles.

  • This sounds like an overkill solution to “lazy programmers”. When pairing, both members may be more productive. In my experience, the pair focus better on the task because they’re working toward the same goal and are less likely to be distracted, especially if both feel empowered to call out distracting behavior. The toughest times I’ve had pairing are when the other person is tied to the mobile phone and constantly texting, making calls, or checking for updates. The best times I’ve had pairing is when we’re both intensely focused on the task at hand.
  • …for Startups, pair programming is often used as a crutch that they can’t afford. Pairing is more expensive, but pairing decreases the risk of things breaking (c.f., How one missing ‘var’ ruined our launch). If you’re in an environment where things can break and you don’t lose money then by all means, atomic batteries to power . . . turbines to speed . . . Zuckerberg’s photos made public. I don’t work for a company like that.
  • My motivations as a software engineer are sourced in personal creativity. If I was forced to program with someone else I would likely quit immediately and find a job that took my skills more seriously. and What an incredible way of making your staff loose [sic] confidence in their coding abilities. I’m concerned about the software teams in which these senior developers are members. As a senior software engineer, you should also be actively working to raise everyone around you and pairing is a great way to do that. A senior is a coach, mentor, and teacher. The best seniors are on teams with very skilled juniors because they made the juniors that way. As a senior software engineer is it your responsibility to just write software or to be a role model and actively work to improve your team’s (or department’s or company’s) practices, skills, ramp-up time, and capability to deliver on commitments?

Yes, pairing is at least 15% slower. I’ve paired on financially impacting code that I could have written in one-third of the time, but the code that came out of the pairing was better organized, more effectively refactored, and had significantly more unit tests than code that either I or my pairing buddy would have written individually. The code worked correctly the first time and later enhancements to it were completed quickly and benefited from the pairing work that went into it. An upfront development cost of four days was repaid by in full before the end of the iteration.

Comments are closed.