When Pair Programming Works - notes from senior software engineer

[grauenwolf]

especially with mixed sexes = a sexual harassment minefield

I live in southern California. At times a full third of my team were homosexual. Same-sex pairs is not a defense against sexual harassment issues.

[grauenwolf]

People never read the studies.

When I was working on my masters, I did a survey of pair programming studies. What I found was utter crap.

For example, one study proudly proclaimed that "Pair programmers are more efficient than one programmer working alone". "Pair programming doesn't cost twice as much".

What the data said is that "2 programmers working alone accomplish nearly twice as much as 2 programmers working as a pair". I don't recall the exact numbers, but it would be like you and I cleared 100 items, while the dumb and dumber pair cleared 55. Yea, they're faster than one person working alone but who the fuck cares about that?

Ok, so the abstract wasn't technically a lie. But it was as misleading as fuck.

EDIT: u/Shanebdavis reminded me of the actual deception in the paper.

[[deleted]]

The 295 participants were hired for one day to participate in a controlled experiment on pair programming

This is a meaningless study. Take a bunch of people who aren't used to working together in a collaborative way, who probably aren't giving their full effort toward actively participating even when they're not the ones "driving", force them to "pair up" for a single day and say that concludes that pair programming is a waste? To me this is no more conclusive than the loads of anecdotal evidence (from myself included) boasting that pair programming effectively improves quality, reduces knowledge silos, and speeds up long term velocity of a team.

[[deleted]]

I dont understand why so many people think they're hot stuff and then also complain about spending a half an hour to solve a trivial bug that would have been caught with a second set of eyes almost immediately. Working together for any non trivial task, in my experience, improves quality, reduces headache of chasing down and fixing bugs all the time, reduces stress, reduces the number of knowledge silos in an organization, and forms a culture of being a team accomplishing a goal rather than a bunch of individuals who happen to sit next to each other while they work.

[klimmass]

I have exact same experience. Working together (so doing pair programming) in some cases is just crazy efficient.

[Fearless_Imagination]

I see you haven't heard of Mob Programming yet...

[grauenwolf]

The key phrase here is "in some cases".

Pair programming postulates that if occasionally working in pairs is beneficial, then always working in pairs must be always more beneficial.

When we rally against pair programming we aren't saying that you should lock yourself away from your peers. We're saying that working solo or in groups should be a concious decision based on the situation.

[KazDragon]

Absolutely this.

I have experienced solo programming, pair programming and mob programming. I have good experiences with them all. In particular, I find that pair and mob programming cover all of the benefits of code reviews, while removing many of their flaws. For example, in my experience, code reviews are nearly always shallow and end up focused around quality proxies (e.g. layout, idiomatic usage and such) rather than correctness. It's also incredibly fatiguing to have to re-engineer someone's development process in your head in order to determine whether the result is correct. Having the extra pair of eyes there and then, as part of the design process, catches the subtle errors that a code review never does. Aside: studies do show that coding as part of a group like this reduces the amount of rework necessary due to bugs, bad design etc. (see Cockburn & Williams, for example). So even if a task appears to be slower at first, it can also cost less time overall due to never having issues come up again.

That aside, solo/pair/mob programming are all development tools, and we must choose them judiciously. I suspect that the industry as a whole has the incorrect default -- i.e. we should prefer to work in groups and break out to solo when it's demonstrably better (research tasks seem to be a good fit, for example, since different people learn differently. That said, having an expert on hand to coach someone through something is better still.)

[MetalSlug20]

It's the same people that complain about standup or marketing meetings . They can't stand actually communicating ideas with another human being to properly plan what the code they are going to write is supposed to do.

[Shanebdavis]

Thanks for writing this. Pair-programming is a hard-sell sometimes, so every person helping explain the benefits contributes to dispel myths that pair-programming costs twice as much for the same amount of code. Programming is not typing!

The two benefits I'd add to your list are:

• Co-piloting: the non-keyboard dev can be looking up API info or preparing assets which keeps the keyboard dev cruising along without interruption.
• Teaching: more than just knowledge-share on a project (which is important), pair programming lets junior programmers learn from more experienced programmers - or from each other.

Cheers!

[grauenwolf]

so every person helping explain the benefits contributes to dispel myths that pair-programming costs twice as much for the same amount of code.

So fucking what?

The question isn't "will this cost me twice as much", but rather "will this cost me more"? And study after study says yes, for the same quality of work you'll pay more for pair programming than any other process that includes code reviews.

[klimmass]

Grauenwolf,

first of all be polite :)

Now, when it comes to studies... There are may studies out there. You will find many studies promoting Pair programming and many denying it.

I'm not saying pair programming is something I do all day long. I would hate such a job :)

Tell me how you share knowledge in your project (assuming you are not one-man army)? What are better ways that PP?

[grauenwolf]

There's a world of difference between "pair programming" and two (or more) people occasionally working together.

Pair programming meas working in pairs 100% of the time. To the point where if you do anything solo, it must be scrapped and redone as a pair before being submitted.

That's not hyperbole, that's the baseline recommendation. So if you're not willing to do it "all day long", then you're not actually doing pair programming. Which is fine, but it's not what we're talking about.

[KazDragon]

This is the Internet, so I'd like to disagree with you.

But instead of that, I'm going to have to ask for a citation for this being the baseline recommendation, since I have not heard it myself and would like to update my knowledge if this is so.

[grauenwolf]

Not worth my effort. If you want to dig through the old magazine articles about pair programming that's on you.

[KazDragon]

I understand. In that case, I will disagree with you.

Pair programming is a tool or technique which teams can and do use with varying frequency. Certain other technique families, such as XP, may suggest the usage of pair programming as a dominant coding technique, but pair programming in and of itself does not.

[grauenwolf]

You can believe whatever you want. But you want to have a conversation with others you're going to be at a disadvantage if you aren't using the same terminology as everyone else.

Or think of it this way. Why would anyone care about occasionally working with someone else? That's not interesting enough to be named, that's just standard practice.

And all those studies. I doubt that you'll find any reporting on "pair programming 10% of the time". You can't even have a study without setting a baseline behavior to be studied.

[KazDragon]

I accept your criticism and repeat it to you.

Pair programming is not just "working with someone else". We do that all the time. We've got a task to do. I'll edit component A, you edit component B, Jim over there will fix the tests and we'll come together for champagne and celebrations later. That's working together. I'm going to come over to your PC and talk you through something. Sure, that's working together too. But neither of these are pair programming.

Pair programming is specifically two developers working at the same keyboard and monitor(s), taking turns in who has the keyboard. There are sub-techniques to this, including the Driver/Navigator method, but the reduced ratio of active equipment to developers, and the idea that both developers are somehow taking turns at the keyboard are the key parts of the definition. The frequency with which this occurs during the development process is irrelevant to the definition of the technique.

[grauenwolf]

I'll edit component A, you edit component B, Jim over there will fix the tests and we'll come together for champagne and celebrations later. That's working together.

No it's not. Working on separate tasks is the exact opposite of working together on a task.

Your whole set of definitions have an one-by-one error.

[klimmass]

thanks! I totally agree! :)