Roy van de Water and Clayton Lengel-Zigich provide a rebuttal to an article that has been circulating within the Agile community this week: High Costs and Negative Value of Pair Programming

 

Transcript

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

Roy van de Water:  And I’m Roy van de Water.

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. 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 para‑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 para‑programming and not just para‑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.

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 para‑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?

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.

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.”

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.

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.

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.

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 customers or developing products for internal customers, where there is a need for that collaboration and giving some creativity, and having that redundancy, so that you don’t have the single point of failure with the one person who knows everything…

Clayton:  That’s true. That’s one thing that’s not really acknowledged all that much. I believe one of the lines in that article states something about like, “If you look at the data in Table three, you can clearly see that the most efficient course of action is to hire a bunch of individual expert programmers.”

If you’ve followed many of our podcasts in the past, then you’ll know that that does not really fly very well with the way we like to work, and that that sets organizations up for failure, because you end up with all of these single point of failure where if any one of them…Each one is a link in the chain, and if anyone is gone, then the organization falls apart.

Roy:  The single expert programmer is usually a hero and a cowboy. They are the ones that are going to stay up until 3:00 AM heroing some solution for some problem, and then they’re going to cowboy‑code their way…

Clayton:  They’re pumping out lots of lines of code.

Roy:  Yeah, exactly, and they’re going to cowboy‑code their way through everything else.

If you ask any IT hiring manager, the idea that you can just go pluck expert programmers off the street…which, to the author’s credit, he does make the point that that probably only makes up about 10 percent of the hiring pool that’s available, the programming talent.

I feel like that advice is…”You should only hire expert programmers” is like telling your little sister, “You should only date guys that are really nice to you, and that are financially secure, and that treat you with respect.” That’s not going to be everybody in the world. That’s probably not very good advice, right?

Clayton:  I don’t want my sister dating everybody in the world, though.

Roy:  I agree, but the idea that a hiring manager is just going to go out there and find some expert programmer and say, “Hey, we can solve all of our problems by hiring three of you, instead of having a few pairs.” That seems silly.

Clayton:  It’s short‑sighted, too, to think of things in terms of moving faster because you have a pair, because it’s a single person moving faster. If you have a single person making poor decisions, and maybe moving very quickly but creating this monstrosity that’s going to be impossible to maintain, sure, you’re moving faster for now, for the next few weeks.

But then, all of a sudden, when defects come in or change requirements come in or whatever, and you start needing to adapt the system to meet the new demand, that’s all of a sudden when things start to slow down, because you didn’t slow down to begin with.

Roy:  Yeah. The way that the example is set up in the article, it’s very tipped in favor of the single programmer, and not in favor of a more, I would say, real‑world scenario, or at least a scenario that we see with our clients that have a dynamic application or a legacy system, or they’re trying to build a new product.

They need lots of creativity, and they need that collaboration, so that they can get lots of different ideas, and so that there’s the redundancy. Those are the things they need. They don’t need people just pumping out code.

Clayton:  That’s, I think, we see in almost every organization that I’ve ever worked with. The biggest problem has always been with figuring out what to build. Not building something quickly. Building something as fast as possible has never been the issue.

Roy:  I would say the other thing, I think, that we see a lot is there are scenarios where saving money is a beneficial thing. I think this article comes from the standpoint, the fact that they bring it up in the very beginning, that Agile is sort of not very good with economics.

Or at least, that’s the claim they’re making. Drives to the point, I think, where all they really care about is the bottom line. Which, you know, I think if you spend enough time in the community you realize that going faster and more better, faster, cheaper. That line, which is, I think, how a lot of people view Agile, maybe Scrum especially.

Clayton:  And Lean as well.

Roy:  Especially with Scrum, if we can do Scrum, then our teams will be faster. They’ll be cheaper. They’ll be better or whatever. If that’s the only thing you’re driving for then I think this article is appealing to you. If all you care about are dollars and cents.

Clayton:  Maybe Agile isn’t for you if you’re doing that.

Roy:  Right, and that’s why I would say that you probably don’t even have the culture in your organization to support para‑programming if all you care about is the bottom line. Because there’s no way you could look at a pair versus a single person and determine that, “Oh, the pair is more expensive, but that’s OK.”

That’s not going to be your mindset. You’re going to think of them as, “This pair is more expensive,” and you’re not going to see the benefits that you get from para‑programming. So you’re just going to ignore out of hand which is who this article appeals to.

Clayton:  Actually, it’s a huge disparity between thinking of these things as just a set of processes and tips and tricks to try to make things more efficient or to make things better, rather than looking at it as a value system, where you are completely changing the way that the human beings within your organization interact.

Roy:  You’re changing the way that people will write that software.

Clayton:  Right.

Roy:  The closing point about divided work. I thought this was just another one to seem kind of ridiculous out of hand as well. I don’t think there’s anything that you could compare between para‑programming, two people sitting down writing software like a software feature. I don’t think that’s comparable to military command whatsoever other than the fact that there are two people.

The idea that you would say, “Divided work can be harmful because look at these examples of things that don’t work.” They’re not the same thing. It’s apples and oranges at that point.

Clayton:  Let’s look at it from the perspective of decision making ability, right? Where if you have two people sitting in front of a computer and they have to make a decision? They could potentially argue about it for half an hour to an hour. In the software development world, like arguing about something for half an hour to an hour is not big deal. But, I could understand in the military engagement that might be a huge problem.

Roy:  Right. [indecipherable 13:04] means software is malleable, right?

Clayton:  Right.

Roy:  You and I could sit down and para‑program and we could come up with some solution. Then, maybe we go away for the weekend, we talk to some friend and they mention something that triggers an idea. We can come back and change that. There’s nothing. You can’t change sending your tanks into battle, and you can’t just do over. There’s no undo.

Clayton:  But, it is pretty common to see, especially large groups get crippled by shared indecision. It’s like everybody wants to go in a different direction.

I can definitely see that extending all the way down to pairs as well, where two people with fundamentally different mindsets want to go in different directions. But, I think that ends up being a much large organizational problem in that probably speaks towards a lack of shared vision for the project.

Because of everybody is on the same page where their project’s headed, then the implementation details of going one direction or another, if they’re both headed in the same way, it doesn’t become as much of an argument.

Roy:  I’ve seen that on teams where pairs will have very…especially, if you get two people that are very strong willed. They will have very different ideas of how the system should be architected or whatever the case may be.

But, when the team doesn’t have trust and they don’t have collective code ownership with standards, that’s when you get people who say, “We should use this library.” Then, the other person says, “No, we should use that one,” when really it’s the team that should basically be figuring out, “When we have to solve this kind of problem, we’re going to do it this way.”

[crosstalk]

Roy:  Once you get over that problem, and you say, I think a great example that we always have with the old Integram was authentication stuff. There are 50 different ways you could do authentication and rails. We picked one and that was how we did authentication. That solved the problem of two people pairing and saying, “Well, my pet library that I think is really great is this one.”

Then, the other person saying, “No, no, no. We should do this way.” Then, it was you had two different ways in this project that were inconsistent with what the team thought was the standard, if you can get over those kinds of things. That’s how you can solve some of those problems that they might seem like problems with pairing, but I don’t think they really are.

Clayton:  That’s true. I think every single one of the items you listed really speaks towards larger organizational problems that have absolutely nothing to do with pairing. Like if these are the things, if these are reasons why you don’t want to do pairing, then maybe you shouldn’t be doing pairing yet because your organization is not ready and your organization needs some significant changes before you do.

Roy:  If you’re totally swayed by the economic argument, then you’re missing all the other benefits that you get. If that’s where you are then you’re not ready to be awesome. If I put my Derek hat on for a second, I would say, “It’s expensive and it’s difficult to be awesome and if you’re going to fall back on some excuse about how it’s too expensive with all these kind of bullshit calculators that you wrote in excel, then too bad. You don’t get a taste of the awesome.”

Clayton:  Fair enough.

Roy:  Thanks. See you next time.

Clayton:  Bye‑bye.

[music]

Announcer 1:  If there is something you’d like to hear in a future episode, get over to integramtech.com/podcast where you can suggest a topic or a guest.

Announcer 2:  Looking for an easy way to stay up‑to‑date with the latest news, techniques and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.

Announcer 1:  The Agile Weekly Podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

Announcer 2:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866‑244‑8656.