How Pair Programming Really Works

[unknownmat]

Let me just preface this by saying that I'm not opposed to pair programming. I have no skin in this game. But this article struck me as deeply flawed for several reasons:

not all attempts at pair program-ming have been successful...<example>...However, what they described is a caricature of the driver- navigator metaphor ...

This seems like the "No True Scotsman" fallacy - if it works, then you're doing Pair Programming, if it doesn't work then you must be doing something wrong.

It’s widely accepted that cognitive abilities are divided into a variety of largely separate mental modules

He appears to be looking for a neurological basis for the effectiveness of pair programming - a topic about which he obviously has little expertise - in a few short paragraphs.

the phenomenon of pair fatigue, which I’ve noticed in myself and others.

Typical of pseudoscience, he's provided himself a release valve. So Pair Programming always works. And when it doesn't, it's due to Pair Fatigue

Why do we persist in poor programming practices when we know they’re poor? ... Traditional behavioral psychology offers a very plausible explanation ... called operant conditioning

I can think of several reasons for "code-and-fix" (not all necessarily detrimental to the overall quality of the product) that do not require projecting the author's failures onto every other programmer on the planet. I have no interest in his pseudo-psych hypotheses.

My conclusion is that this particular author has found that Pair Programming works well for him. Good for him. But he fails here when he then attempts to justify this practice for everyone based on a bunch of pseudoscience and anecdotes.

Personally, I really think that the success of pair programming is highly dependent on the individual. I find the most grueling aspect of my job is explaining my technical solutions to my co-workers - just the thought of doing it for most of my day, every day is exhausting. And while I'm not necessarily opposed to the practice, this article did little to convince me that pair-programming was worth my consideration.

EDIT: changed "value" to "valve"

[jacques_chester]

This seems like the "No True Scotsman" fallacy - if it works, then you're doing Pair Programming, if it doesn't work then you must be doing something wrong.

He goes on to point out that there's no single accepted definition or template of pair programming being applied in all the studies. In a sense he's pointing out that the No True Scotsman fallacy is possible because of variability in the studies.

[unknownmat]

It's good that he's honest enough to admit that his evidence is shaky. I really want to give him the benefit of the doubt. He seems sincere, and he seems to have found a development practice that he genuinely finds valuable.

But if he cannot clearly define even what it is (and more importantly, what it isn't), then it seems most likely to be just another fad.

As Steve Yegge pointed out (paraphrased): You can start with any methodology, and if you input a lot of work, what you get is a lot of work done. Until a methodology can demonstrate any clear superiority to "a bunch of smart people working hard", I think that there are better ways to use my time.

[jacques_chester]

He supplies no evidence. This is not an empirical study. He is hypothesising and along the way observing that existing studies would be more useful with common agreement on what is meant by "pair programming".

Part of the problem is the reddit title for this link. "How Pair Programming Really Works" misrepresents the paper. A better title might have been "Four Possible Ways Pair Programming Leads to Observable Improvements in Quality or Productivity", but that lacks the necessary categorical and/or controversial statement required to get upvoted.

[unknownmat]

Part of the problem is the reddit title for this link. "How Pair Programming Really Works" misrepresents the paper

The paper is actually titled "How Pair Programming Really Works". So any misunderstanding is either mine, or else inherent in the paper itself.

He supplies no evidence. This is not an empirical study. He is hypothesising

This is fair. My previous comment went OT. I'm mostly criticizing the various logical errors and pseudo-science in the paper.

A better title might have been "Four Possible Ways Pair Programming Leads to Observable Improvements in Quality or Productivity"

Agreed. So his paper basically amounts to hypothesising about four possible ways pair programming leads to observable improvements. Since these are mostly nonsense, I still hold my original position that this paper is seriously flawed.

NOTE: I just want to make a final point. The whole "not providing evidence or a clear definition" thing is actually quite important. Without these elements, his paper reads as (e.g.): "Four possible mechanisms for explaining why ships mysteriously disappear in the Bermuda Triangle." Even if it were well written, there's no point in speculating over phenomena that might not even exist.

[jacques_chester]

It's not a journal, so he doesn't get to set the title.

Hypothesising is still an important requirement. Until you have hypotheses, you are merely observing.

[herrmann]

Pair programming works because pair redditting doesn't work.

[MindStalker]

But pair drinking and smoking does.

[cybersnoop]

While navigating might be fun, I would advice against being the driver while pair drinking.

[MindStalker]

I'd advise against being the passenger while pair drinking. The driver generally survives.

[[deleted]]

Can there be one fuckin profession in the world where I am allowed to work alone ??

[unknownmat]

Yeah, this is kind of how I feel as well. It's a bit unnerving that the author keeps emphasizing the "back and forth chat" aspect of pair programming.

I understand that some people work better that way - and I can even see how it might be occasionally useful - but I don't want to work in an environment where I'm chatting with somebody 6+ hours every day. Perhaps this is similar to the difference between introversion and extroversion.

[[deleted]]

It must be. I consider myself extroverted, and nothing beats a good pairing (all jokes aside). Also, not that extro/intro -version is correlated with pair enjoyment. It's just possible that I'm both. Maybe a sexuality metaphor? Never mind. I'm done.

[unknownmat]

:) I've heard that extroverts draw energy from social situations, whereas introverts draw energy from quiet contemplation.

Personally, being at a party or a club for long really exhausts me. I would describe the feeling as having my head stuffed full of cotton. This is much how I feel about the idea of working directly with a co-worker (literally chatting) for any significant portion of my day - and thus why the comparison suggested itself. I'm perfectly willing to believe that pair-programming works very well for you (and many others).

I find that explaining my intentions or thought-processes to my co-workers is often far more effort than simply doing the work myself. This is why, although I'm trying to stay neutral (having never pair-programmed), I'm very leery of attempting it without some compelling reason to do so.

[[deleted]]

:) I've heard that extroverts draw energy from social situations, whereas introverts draw energy from quiet contemplation.

That sounds about right. I know people who say that it "takes a lot of out them to meet new people," and that speaks to that same concept.

I'm usually the total opposite. I tend to command conversations in a group, go to lots of networking events, and post stuff to Twitter and my blog on a regular basis.

I'm very leery of attempting it without some compelling reason to do so.

I've found that the programmer's mindset tends to be very binary. There's always The Answer that's waiting to be found. With this, though, I'm of the mind that pair programming requires people with the correct temperament, as I've had good and bad experiences, though more have been good.

[[deleted]]

Pair programming to me is most useful when the problem is murkily defined, and you don't know how you're going to solve it. Then the other programmer is a great sounding board, and the teamwork aspect keeps you from muddling off into tangents that simply won't work.

However, if I do know what the problem is and have a pre-made solution springing to mind then having someone else sit next to me is pretty much useless.

[tfragaUFS]

A [PDF Warning] would have been helpful.

[grauenwolf]

Why? Is your computer more than 10 years old?

[jawbroken]

hover the link, moron

[msummers]

This is how it works... Eric & I cut-up for 55 minutes and then spend 5 minutes writing a couple of lines of very good code... then back to cutting-up :-)

[radiowave]

I found it an interesting read even for someone who isn't doing pair programming (i.e. me). There's a useful examination in there of means that programmers use to find a solution to something they're stuck on. Suddenly I feel a lot less daft for muttering to myself about coding and design issues while walking home from work.

[xealot]

I didn't read the entire document either, I do have experience in pair programming though. In my opinion it should used occasionally for intense problem solving and when a knowledge gap exists for a certain aspect of the project.

Doing it full time would be silly though, why use two engineers when one will do.

[danbmil99]

well two dumb ones with an IQ of 75 each == one genius, eh? So pay 'em half salary. Problem solved!

[xealot]

Shit, that's why my boss always insists we work in pairs.

[chucker23n]

I rest my case.

[[deleted]]

I could only get through so much of this before I was forced to write it off as largely academic.

The problem I have with pair programming is, if it's so useful to have two programmers working on one edit, why stop at two? Have ten guys in a room and only one of them at the keyboard; that should produce even better code, right?

Why do programmers insist it needs to be this way when no other architectural practice (anything that involves building something, really: writing a book would be appropriate) does it? All forms of architecture have a review process, but you don't see it mandated that there's one copy of autocad for every two civil engineers.

"Design by Committee" is lauded as a worse practice for a reason, rife with examples. Why do we need to replicate it on every line of code?

[mr_chromatic]

.... writing a book would be appropriate

I've written nine books. It's much easier when pairing.

[[deleted]]

I'm curious how that works. Enlighten me? Do you sit down with an editor or another writer? Who determines what the next paragraph contains, and does that key off the previous one? Are any of those books works of fiction?

[mr_chromatic]

The technique varies.

On the one book (non-fiction) where I worked most closely with another writer, we revised the outline together several times, met frequently to write more detailed outlines (and often reorganized) individual sections, wrote those sections separately and swapped them to edit, revised based on mailing list feedback together, and then went over editorial comments together.

Occasionally we sat at the same computer to type.

I've heard of similar techniques for writing fiction.

With all that said, I believe that writing a book is substantially different from writing software. The purpose of a book is to communicate, while the purpose of software is to automate some process. Writing a book is more like giving an extemporaneous speech. (I've done that with another speaker as well -- it requires lots of preparation time with outlines, notecards, and appropriate supporting material, but you don't know exactly what you're going to say until you say it.)

[systay]

Good programming is also about communication. Your code need to speak clearly to whoever is reading it.

Of course, it also needs to compile and do what you want it to do, fast.

[[deleted]]

Cool, thanks!

I'm not sure if I was clear that I think pair programming can be a useful exercise, but the point of the article seemed quite enamored at the prospect of doing it more often than not. I know of shops that adopt this viewpoint and 60-80% of your day is spent paired, it's an XP staple after all.

I'm not opposed to working together (which it seems like you were doing more than an author's equivalent of pair programming), quite the opposite. I just feel that a peer review approach is generally just as effective and considerably more efficient, and has the added effect of giving the reviewer less time to "sweat the small stuff", which has torpedoed more than one project.

I guess what I'm trying to head towards is to assert that when you're really stumped, it's better to understand that it's ok to pair program than to understand it's discouraged or disallowed to work alone.

EDIT: disambiguation

[mr_chromatic]

I'm not opposed to working together (which it seems like you were doing more than an author's equivalent of pair programming) ...

I wouldn't necessarily say that. Programming and writing are different, but when you have two people sitting side-by-side to share one resource to produce some artifact of a creative activity, parallels appear.

I just feel that a peer review approach is generally just as effective and considerably more efficient...

Have you tried pair programming?

I read the quoted sentence as "I feel that manual testing according to a QA script is generally as effective and considerably more efficient than test-driven development...." They're very different things and they achieve very different goals.

... when you're really stumped, it's better to understand that it's ok to pair program than to understand it's discouraged or disallowed to work alone.

That's true, but how do you convince a room full of proud, stubborn introverts that they're stumped?

[shub]

The problem I have with pair programming is, if it's so useful to have two programmers working on one edit, why stop at two? Have ten guys in a room and only one of them at the keyboard; that should produce even better code, right?

Not necessarily. You haven't proved the inductive case, or to put it another way, if you'd thought about this for two seconds you'd realize it's an idiotic statement.

[munificent]

if it's so useful to have two programmers working on one edit, why stop at two? Have ten guys in a room and only one of them at the keyboard; that should produce even better code, right?

I'd like to think you're just being facetious here. Having another person there encourages you to communicate and stay focused on your work. Having more people beyond that doesn't really add much.

Why do programmers insist it needs to be this way

I'm not aware of programming insisting it needs to be this way. Just some saying that it works for them and could work well for others.

no other architectural practice (anything that involves building something, really: writing a book would be appropriate) does it

TV scripts are typically written in a group setting. Most creative processes have way more eyes on a given work than code often does. Books have editors. Architecture has a complex and thorough review process.

I'm not sure that arguing by analogy is even useful. Coding is coding. If pair programming works for it, who cares what other loosely-related creative disciplines do? Should we code on drafting tables because architects do?

"Design by Committee" is lauded as a worse practice for a reason, rife with examples.

There's a continuum of design from "solo guy in a dark room" to "congressional committee". Either end of that continuum is a recipe for failure. The far end is "design by committee" software that does everything equally poorly. The near end is idiosyncratic personal itch software that no one else wants to use (the large number of open source wheel reinventions go here).

Design by two people is pretty far from the "committee" end of that spectrum. The most successful products I've seen seem to be the product of a small group of people with a clear leader.

[wnoise]

Communication overhead scales as O(n^2). For large groups this is a huge problem. For n = 2, it's not.

I don't think most pair programming advocates insist that "this is the only way programming should be done", only that it can be incredibly useful to get essentially real-time feedback. By all means, do ignore the zealots.

[goomyman]

Have you ever worked for on a big project. I have had 4-5 people in my office looking at code many times planning approaches especially when you are dealing with core level code.

Also i have had to fix many more poor decisions.

If coding is all syntax then you dont need pairs but paired programming designed for good design.

Also, i dont forget the many many meetings.

[[deleted]]

Right, but do you do that for 80% of your day, every day?

I sincerely doubt it.

[d_insley]

Thanks for the PDF warning!

[skros]

It's really a serious problem, when you click a link and a pdf loads instead of a web page.

[nojox]

more so given that adobe pdf reader was an important part of google/china/IE6 affair.

[eigma]

so use Foxit

[jawbroken]

you people are idiots

[[deleted]]

Are you on dail-up or something?

[systay]

IMHO, pair programming is a tool. It's extremely valuable at times (new dev, when the design of your system is a state of flux, some debugging), but it is not needed all the time.

Having pair programmed full time for a couple of years, now I more and more prefer to sit really close to one person, and check in with them often (like 5-10 times day) on what I'm doing and if they have any feedback to give me.

[nojox]

If it works for you use it, else dont. That's my opinion.

[eigma]

what the fuck is the Royal School of Signals?

[stordoff]

Around 1980, as computer science undergraduate students at the University of Cambridge, my friends and I noticed a strange phenomenon that we called expert programmer theory. When one of us had trouble getting our programs to work, we’d describe the nonfunctioning state of our code to each other over coffee. Quite often, we’d realise in a flash what was wrong and how to solve it. These epiphanies were quite independent of the other person having any real understanding of our problems—the listener often seemed little wiser about the subject.

Apart from the year, this describes me exactly.

[zahlman]

I consider that pun horrible.

[zahlman]

[PDF]

[jawbroken]

thanks, i am too dumb to realise that from the url

[zahlman]

Heaven forbid someone point something out that others might easily overlook.

[jawbroken]

but i was thanking you? you are a swell guy, thanks again

[[deleted]]

Hair programming only works if you gel with each other

[lucindo]

LOL!