

How Pair Programming Really Works - obiefernandez
http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2010/0110/W_SW_PairProgramming.pdf

======
mnemonicsloth
From the Site Guidelines:

 _Please don't do things to make titles stand out, like using uppercase or
exclamation points, or adding a parenthetical remark saying how great an
article is. It's implicit in submitting something that you think it's
important._

<http://ycombinator.com/newsguidelines.html>

EDIT: That said, good read.

~~~
obiefernandez
Mea culpa. No harm intended, just had never read the guidelines.

------
veezus
+1 - A fact-based discussion of the reasons I am of one those programmers that
love pair programming.

Regarding the Expert Programmer Theory: I find it rare that my pair and I get
'stuck'. Rather, discussion at the early stages of implementing a plan head
off any decisions that will end up with us being stuck.

That said, the times I usually find my pair and I getting stuck is in the
naming of concepts within the domain. At this time, polling those developers
around us helps out enormously.

Regarding 'change blindness': This is where I find some of the most value from
pairing. I find that I get (and give) a lot of value in the catching of minor
logic errors, changed method or variable names, and simple typos.

------
mhartl
I'm certainly no opponent of pair programming, but its proponents often seem
not to address the 0th order argument against it: the parallel/series problem.
To complete tasks _A_ and _B_ , Alice and Bob can finish them in parallel if
they work alone, but can finish them only in series if they work together.
This means that, for equal-sized tasks, solo programming is _a priori_ twice
as productive as pair programming. I'm perfectly willing to believe that the
benefits of pairing can overcome this factor (and more), but that's a strong
claim and requires strong evidence.

~~~
gvb
In my experience (24 years in a large company doing a lot of large projects),
the coupling of different pieces of the program is _severely_ underestimated.
The result is that The Plan lays out the schedule with Alice and Bob working
in parallel, but in reality they end up requiring a lot of interaction before
the project is done.

Typically in a large project, Alice and Bob work independently but make
different assumptions and have to rework a significant amount of their code
when they finally get together to integrate their two parts.

In my experience, large teams can shrink calendar schedule time by brute
forcing the dependency failures. The trade-off to achieve schedule compression
is substantial inefficiencies and often a loss of quality and maintainability.
I am convinced that a lot of schedule slippage in large projects is due to
incorrect assumptions with respect to the independence of the pieces. While it
is possible to compress the schedule this way, all schedule compression that
exceeds the true parallelism in the project requires exponentially increasing
effort to overcome the inefficiencies due to the coupling.

This is behind Brook's Law <http://en.wikipedia.org/wiki/Brookss_law> "2.
Communication overheads increase as the number of people increases."
Communication overhead is the indication of coupling of the pieces. If Alice
and Bob's pieces were truly independent, they would not need to communicate
and Brook's Law would not apply.

The physical analogy to the effort required to shrink calendar time is the
"hull speed" of boats. <http://en.wikipedia.org/wiki/Hull_speed> and
<http://en.wikipedia.org/wiki/Wave_making_resistance>. While it is possible to
"escape your bow and stern waves" (i.e plane), it takes an exponential amount
of power to do so. (The first wikipedia page links to another nice
explanation: <http://www.antrimdesign.com/articles/hullspeed.html.>)

------
unfletch
A former co-worker of mine went to work at Pivotal Labs, where full time
pairing is the mandate. After just a month, he quit "the best company he'd
ever worked for," and wrote up a lengthy blog post on why pairing didn't work
for him: [http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-
pro...](http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-
and.html)

------
bryansum
Reading this article reminds me of a small company in Ann Arbor, MI called
Menlo Innovations (<http://www.menloinnovations.com/>), which pair programs
exclusively. Their founder has spoken at our university a number of times
about the effectiveness their methods. In my eyes this article quantifies to
some extent what he's said.

------
voxdolo
It's really nice to see a formal review of something I've learnt organically.
Good read and really interesting reflections on the practice.

------
obiefernandez
The most spot-on description of the benefits I've ever read. Balanced and
scientific treatment of the subject.

------
julius_geezer
I don't do it formally, but it often happens that I'm sitting at a co-worker's
machine and asking to have the mouse or keyboard. We do spot each others'
typos, but I drive her nuts with my preference for the caps lock key.

------
adam_lowe
Very solid write up.

