
Ask HN: How useful is Pair Programming? - aj
How useful and practical really is Pair Programming? Does it really work and scale up well?<p>What are the advantages and disadvantages? Statistical data/study would help.
======
Edinburger
I've led agile teams for the past three years where there has always been some
pairing and some solo work. I'm sorry I can't offer statistical data, only my
anecdotal observations:

* Pairing is particularly useful when breaking new ground.

* Pairing is good for knowledge sharing.

* Pairing is good for quality.

* One pair is slower than two solo developers.

* Based on the last 3 years I don't buy the idea that long-term pace is higher because we'll have less technical debt due to pairing.

* Improved quality may not be worth the lower overall pace

* You hired professional developers - let them work the way they think is best or find new developers i.e. respect their preferences for pairing or going solo.

~~~
aj
> we'll have less technical debt due to pairing.

Could you explain this point?

I think most of the points you make a pretty good points. I have not worked in
a pair programming environment myself but find it quite attractive. Mainly
because sometimes I tend to rapidly analyse multiple ideas for pros and cons
and to try and break them and having someone as a sounding off board is
something that I would like.

~~~
Edinburger
Sure - this point starts with the idea that pairing is slower in the short
term but creates higher quality software. We might also believe that pairs
will create systems which are easier to maintain i.e. pairing leads to better
systems design. So, we might believe that it will be cheaper to change those
systems in future and we won't be spending so much time fixing 'technical
debt' (solutions which turned out to be poor technical choices). Some
advocates of pairing will claim that this means pairing will actually be more
productive than solo work in the long term (since those solo folks will be
spending more time wrestling with poorer quality code and less well-designed
systems). In my (limited and subjective) experience I haven't found this to be
the case.

~~~
aj
Ah.. Oh.. Well, logically, I came to that conclusion as well (as indicated by
my comment) You comment indicating otherwise needs more investigation. I wish
there was some statistical data to help determine this more conclusively :)

~~~
Edinburger
Yep, unfortunately
<http://martinfowler.com/bliki/CannotMeasureProductivity.html>

------
menloparkbum
Pair programming is useful when the project is so heinous and boring that
nobody would work on it unless there's another person sitting next to them
keeping them on task.

~~~
gcheong
I think you just described my entire CS undergrad experience.

------
akeefer
Microsoft did an internal study you might find interesting:

[http://research.microsoft.com/en-
us/um/people/abegel/papers/...](http://research.microsoft.com/en-
us/um/people/abegel/papers/esem-begel-2008.pdf)

I also know that they sponsored research by the Stanford CS department where
they gave pairs and individuals the same programming task (completable in an
afternoon), but I have no idea what the results of that were or if they were
ever published.

My personal experience is pretty analogous to other people's: it causes you to
work more slowly and carefully, it's good for knowledge transfer, and some
people are better suited for it (personality-wise) than others. I find it most
effective when avoiding errors or technical debt is imperative or when you
want to transfer knowledge, and not as useful otherwise.

I've also noticed that my perceived productivity is lower when pairing than it
actually is; I'm so used to cranking by myself that slowing down so someone
else can talk with me about what to do, or being the "navigator" and not
coding at all, makes me feel like I'm not getting anything done. In reality,
though, I'm actually getting a fairly decent amount done, and more importantly
we're probably avoiding mistakes or blind alleys that would have cost me time
in the long run. That makes it hard to measure the real productivity
difference: if two people had coded by themselves for 8 hours, more "work"
would have been done than if those two people paired for 8 hours, but how much
of that would have been wrong, or unnecessary, or overly-complicated, or
introduced more technical debt?

It's the sort of skill that takes work, and that gets easier as you do it, so
I'd encourage you to try it out. As with any new way of working, it'll be
awkward at first and then get easier, and I think it's worth at least learning
so that in the future you'll be able to judge for yourself when you feel like
pairing will be most useful and when you're better off flying solo.

~~~
aj
I think that is the most fuzzy part. Determining combined productivity,
factoring the "improved" quality and the knowledge sharing and gain is a lot
more difficult than simply adding up the individual productivity of each
programmer (whatever may the metric for measuring the productivity be), but in
this case, not tending to factor in improved code quality, constant code
review and higher probability of catching subtle bugs

------
mpk
Pair-programming as a dogmatic part of the development process is, IMNSHO,
very overrated.

Coding standards, simple interfaces, commit policies, etc are far more
important.

Pair programming is useful for,

* Building small but critical pieces of code which everyone interfaces with on some level inside a group (a core plugin API would be a good example)

* Knowledge transfer. I use PP extensively to work-in new people and get them comfortable with a codebase, svn commit policy, documentation, etc. (I let them choose the tools, read on for more on that).

* Solving short coding problems in a common piece of code.

Code review also plays a much more important role than PP. The ability to
read, understand and change each others code should just be built into the
development process instead of trying to force an artificial level of
quality/shared-knowledge via PP.

As an example, in my spare time I'm implementing a simple and clean Ruby
version of some core functionality that we have in C# and JS (yes, I know, odd
combination). A colleague is tracking my commits and implementing the same
system in Python (also in his spare time). At any point in the future, someone
wanting to implement this in Perl (for example) can just follow the commit
changes on this reference implementation.

PP is also tricky when you choose to do something other than C# or Java,
because in those cases you have a common IDE that's used in the company.

If you're doing anything unix-y some people will use emacs (setup _their_ way)
and others screen + vim (setup _their_ way). Some poor misguided fools will
use Notepad++ on Windows, and while that's fair enough if it works for them,
that doesn't help matters any for PP.

I'm not dismissing PP, but the XP model just isn't suited for every
environment.

------
DanielBMarkham
From what I've seen, this is something with a lot of hype. I've seen a lot of
smoke, but little fire.

Anecdotally, I've heard and seen that it helps, and that it hurts. I've seen
people praise it as the answer to all productivity problems (along with TDD
and ATDD, of course) and I've seen people curse it.

My opinion? It's good for leveling out the programmers on a team. If I had 6-8
team members I might have one pair going at all times -- usually the pairing
up a weak/new developer with somebody who can help him. But I wouldn't expect
productivity improvements -- I'd simply use it as a way of level-setting the
team. It seems like a good mechanism for bringing people up to speed quickly.

Having said that, you have to let the team be the judge. If they like it, do
more of it. If not, don't. Whatever you do, don't let hype and religion get in
the way of the team performing. Life is too short to make it miserable by
doing something everybody thinks is stupid.

Some of the TDD guys are doing ping-pong pair programming. That's where person
A writes a test for new code, then person B writes code for the test and then
writes a new test for new functionality. It bounces back to person A, who
writes the new functionality and then a new test for new stuff, etc.

That at least seems more interesting for folks.

Personally, I don't like it. But I try to be open-minded about it (especially
since I teach this stuff!)

Be aware that in some anal-retentive shops, pair programming is a security
violation. (You're not supposed to be sharing your terminal session with
anyone)

------
blasdel
Almost all of the methodology promoted as "Pair Programming" is at best
neutral, but there is a kernel of awesomeness in the idea:

Get two developers working in close proximity, criticizing with each other
constantly as they work. The more yelling the better.

------
seshagiric
The bloke in my next cubicle practices it and I hate it!

All day long they are always discussing where to put an if condition, assert
or what to name their variables. And fuck I cannot concentrate.

------
andrewljohnson
I've read that pair programming is good for mediocre or novice programmers.

~~~
HalcyonMuse
Citation?

------
nshah
There's both sides of pair programming... recently I attended a presentation
where the presenter basically said that pair programming should be
mandatory... on the other hand, I've done pair (and even triplet)
programming... Here's my thoughts:

* Advantages \- Works great in initiating a new team member in to a large project \- Gives each developer a chance to do code-review on the fly \- If there's good rapport, pair programming can get a lot more done

* Issues \- Requires good co-ordination between team members \- Two similar thinking people may not be able to take full advantage of this technique

------
gcheong
The fact is that very few studies have actually been done so most of what you
get are anecdotal accounts. I think pair programming has it's uses, for
example, when a developer is stuck on a problem and can't move forward it's
often helpful to have another set of eyeballs, but I have yet to see it
effectively used full time (except for consultants who get to bill out at a
double rate!).

A good book to check out with some counter arguments to pair programming and
XP in general is "Extreme Programming Refactored: The Case Against XP".

------
dkarl
In my experience, pair programming is to programming what eating less and
exercising is to obesity: most people simply can't bring themselves to do it,
even after trying it and experiencing success. My advice is to just forget
about it, like doctors these days who prescribe drugs for cholesterol and high
blood pressure without even bothering to mention that those conditions can
usually be controlled via lifestyle changes. Unless you're really lucky, you
won't find anybody else willing to practice it with you.

If you actually get a chance to introduce pair programming to your
organization, go for it. In my unfortunately limited experience, pair
programming paid for itself by virtually eliminating some classes of mistakes.
Typos and other oversights are caught faster and more efficiently, of course,
but more importantly, things that lone programmers tend to put off figuring
out, the mental and sometimes subconscious TODOs, get hashed out immediately.
That saves time rewriting bad designs.

Unfortunately, as with lifestyle change, people start enthusiastically but
quickly sour on it until the mere mention of it evokes anger and resentment.

------
intellectronica
_very_ useful, but not exclusively. pairing is great for gaining momentum,
learning a new technique or domain, focusing on solving a particularly hard
problem and mentally syncing with your co-prorammer. it is draining and
ineffective if done for more than a week or two.

------
philcrissman
If you have access to trade journal type archives (IEEE, ACM, etc) you can
find a lot of articles/studies on pair programming. Most of those that I've
seen tend to be positive in their attitude toward pairing, though it's
sometimes hard to tell if bias is at work there; also, many are in an academic
setting environment rather than a corporate or startup/consulting environment,
which may lead to some different results.

If you're a student, or know one, it's very probable that your school's
library might have online access to some of these journals. If you want
statistics, that might be a good place to start.

------
snprbob86
This was discussed on HN recently. Lots of good comments here:

<http://news.ycombinator.com/item?id=490173>

~~~
aj
Ah.. Thanks for the link. I missed that during my vacation..

------
jimfl
Three words: Pair as needed.

~~~
brc
Couldn't agree more. Any set of talented developers in an open environment
will naturally pair when one or the other has a critical piece of code to
write or some code they want input on. The key is getting the right sort of
developers who know when they are stuck, and a no-blame environment where you
can be called on bad code decisions.

Trying to mandate this sort of sharing through policies strikes me as
ridiculous and the sort of thing that drives good developers out. Training a
junior is one thing, having them assigned to 'help' is something entirely
different.

I've always thought of pair programming as something that consultancy firms
dreamed up to charge clients twice as much for the same amount of work.
Perhaps I'm just cynical and tainted as it was a highly-paid consultancy firm
that first tried to sell me on the idea.

