Clayton Lengel‑Zigich: Welcome to another episode of the “Agile Weekly Podcast.” I’m Clayton Lengel‑Zigich.

Roy vandeWater: And I’m Roy vandeWater.

Pair Programming Not Scientific

Clayton: Today we’re talking about an article that we came across, it was this week. It’s called the “High Costs and Negative Value of Pair Programming” Original Taken DownHacker News Thread. It’s by Capers Jones at the Namcook Analytics blog, we’ll put that in the iTune net.

Basically, it’s, like a white paper almost, about why pair programming is harmful, and it’s not really a good idea, and you shouldn’t do it, or at least, you shouldn’t do it yet, until you do lots of research about it. It struck a chord, I guess. We came across the post on Twitter, and it kind of generated some buzz on there. Then, we talked about it internally, so we were hoping to share our ideas.

The first point that I thought was, that resonated with me was the author makes mention that pair programming is something that came out of the non‑scientific. It wasn’t measured very well in the Agile community. I would probably give him that, that the Agile community has lots of things that we do that are not necessarily based on hard scientific evidence, a lot of its just anecdotal experience. That’s probably a fair statement.

Roy: It becomes very difficult, too, though. I think we’ve had something that we’ve run into in the past, right? Where it becomes, because of the nature of every team being different, different projects being different, the codes bases being different, like a lot of the pair programming and not just pair programming, a lot of the types of practices that teams are experiencing with are very difficult to measure in a scientific way. It’s very difficult to have a control group that’s identical except for this one variable.

Clayton: The thing that was…while I agree with that general idea that the Agile community is very unscientific about how they measure things, I felt the way that they went on about, goes without measuring things in the article was kind of lame because they just made up a bunch of stuff and put it in Excel it seems like. I don’t know. My guess is you have to take a healthy grain of salt.

The Nature Of Organizational, Team and Work Variety Makes Data Collection Difficult

Roy: The thing that I thought was most interesting in the beginning is that the author tries to make the point that there are a lot of different scenarios about pair programming that were not considered in most cases. He goes through all these different examples of single programmers using static analysis versus expert single programmers compared to average pairs and novice pairs compared to all these ten different permutations of all these different things.

Which, I guess, there are probably not many organizations that have all of these things and they are only going to have two or three at most. I thought it was odd that you go so far out of your way to make a big point of not comparing all these things, especially when there probably isn’t a whole lot of opportunity to compare them all?

Static Analysis A Poor Benchmark

Clayton: I thought the static analysis bit was interesting because he specifically talks about the number of defects that a single programmer using static analysis produces versus two pair of programming produce. I think the ratio is something like a single programmer using static analysis develops one defect for every 15 that the pair programmers develop? I guess maybe I don’t understand what static analysis is, because I don’t understand. Do you mind explaining real quick?

Roy: The idea that static analysis is going to evaluate your code and find defects for you? I have written plenty of defects that static analysis wouldn’t have caught. There’re plenty of things that static analysis would tell you that wouldn’t be defect that you could spend a bunch of time fixing. That seems like it’s just a silly thing to even bring up.

Static analysis can be important and it can hint you in the right direction and help you find different things with your code. The idea that it’s like this great tool for finding defects or even a tool for finding defects seems like a stretch.

Moving on, another downside the author states for pair programming is that it won’t scale. The example that he gives is a huge software project with 500 engineers. How could you get them to pair? How could you hire another 500 more people? Which seems odd, because any software project that had 500 people working on the same thing that sounds like a nightmare, no matter what you’re doing.

Can Pair Programming Scale

Clayton: Right. Exactly. You are going to have so many people doing many random things and wasting a ton of time, even pair programming at that point when you have a project that big, it becomes unmanageable.

Roy: If it’s 500 people across an entire organization all working on different things, then you could still pair. There’s nothing that says you couldn’t, the idea that it wouldn’t scale? That seems kind of silly.

Clayton: That’s the mindset difference, right? Because he’s thinking from the perspective of “I have 500 people and I need to maintain my current productivity level, which means I have to hire 500 more.” Instead of saying, “I have 500 people and that means I have 250 pairs.”

Is Pair Programming Only For Developers

Roy: That’s a good point. Kind of the next thing that is the problem with pair programming is why hasn’t this been tried with other business functions or other job functions? They talk about architects and BAs and testers and all these other things which, if you talk to those who are actually doing pair programming, they have tried to do some form of pairing with people who are not just software developers.

This one stuck out to me as someone that has kind of betrayed the experience the author has with pair programming and the idea that no one has tried that before.

Blended Skill Sets Amplify Pair Programming Effectiveness

Clayton: In fact, in my experience, the biggest gains from pair programming come when you have the most different types of experiences combining. Say, you have a graphic designer and a programmer, or something like…as different as possible.

Because, if you put two people that are almost identical in front of a computer, the most you’re going to get out of it is maybe a slightly lower defect rate, because one of them is proofreading what the other one is writing.

But, if you have two people that have totally different ways of approaching the problem that gives the pair a greater diversity of options to choose from, and it makes it more likely that they might pick the right one.

Lines Of Code, The Bullshit Indicator

Roy: The thing that struck me as the biggest bullshit indicator of the whole article was that one of the measurements that’s used in this calculation is lines of code. The measurement is how fast is an expert single programmer, based on how many lines of code they write?

That’s what is used in all the economic calculations. I wouldn’t doubt that pair programming is probably more expensive, and probably slower, than single people working on things, but that’s entirely ignoring all the other benefits that you can get.

If you’re just doing lines of code, if you’re working on a software project that all that matters is that you’re just pumping out lines of code, then just hire a bunch of monkeys and they can just pound on the keyboard. You don’t need pair programming at that point.

It seemed like an odd comparison. I would even say that if your software project is so simple that you can just crank out lines of code, then you probably don’t get any benefit from pairing as far as collaboration, or redundancy or anything.

If Collaboration Doesn’t Matter, Outsource It

Clayton: You probably don’t get any benefit from collaboration of any form. You should probably just outsource, and try to get your code written as cheap as possible.

Roy: Right, because if all it really takes is that you just are pumping out code, then you can just replace that person with someone else, and it doesn’t matter. But, that’s not the case, I think, in most software organizations.

Clayton: I was going to say, how many projects are actually out there where you can just put anybody in front of it and pump out code?

Roy: A lot of people try and do that, especially, I would say, shops that are doing outsourced software development, where they’re solving the same problem multiple times. They probably do just have a set way of doing things, where they could get pretty close to just pumping things out, and it doesn’t really matter who’s working on it.

But, for most organizations that are developing either products for cus