
Pair Programming Considered Harmful? - Qwl
http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/
======
jonstjohn
The company that I currently work at uses pair programming extensively - not
100% but strives for 3 hours per day. Although I understand its value,
actually doing pair programming can be exhausting and tedious. I've also found
myself working twice as hard/fast during non-pairing hours b/c I knew that
pairing would sometimes be painfully slow. Lately, I've tried to work
productively with my pairing partner in tandem, rather than sitting in front
of a monitor together 3 hours a day.

I love the company that I work at, so I'm not likely to let pair programming
dissuade me from staying there, but when if and when I do look for a new job
(or start my own company), I would be very wary of a shop that uses pair
programming extensively. I really love working in a team and directly with
others on projects, but pair programming can be very tedious, particularly if
there is a big gap in experience between the two people in the pair.

We also use code reviews for all code that goes to production. I find this to
be extremely valuable. For more complex pieces of code, we do 'design
proposals' that are circulated within our small team (4 developers) to get
feedback and improve the design of our code.

~~~
osivertsson
Yes, it is my experience too that pair programming works best when you both
are at roughly equal levels of experience and both really want to succeed with
the task at hand.

Code reviews in groups often work really good despite different levels of
experience though.

It is exhausting to do pair programming, but when it really does work the
feeling of progress and mutual knowledge sharing is awesome. In these optimal
cases me and my coworkers have worked in pairs for 5-6 hours per day. Pushing
on for longer would not have gained anything, rather the opposite.

~~~
mtts
I work with a lot of interns these days, doing what's essentially pair
programming with them and I don't feel their lack of expertise brings me down
at all. Instead, I find having to explain everything I do to them brings a
clarity to my own mind that is difficult to obtain otherwise.

Of course it does help that when my explanations truly fail, I still have the
nuclear option (Hey, they pay me to teach you this stuff, so just believe me)
available, but (I'd like to think) I only rarely use it.

------
mattiask
I actually think pair programming cons/benefits is part of a larger pattern
that I call "management overhead". The premise is any practice implemented to
increase general quality risk being offset by decreased productivity of the
top performers.

If you have skilled developers they will work more efficiently the less
"management overhead" that is put upon them (processes, checklists,
methodologies etc). They will simply self-regulate and a large amount of
output of high quality. As the skill/experience of the developers in an
organization drops management typically implements practices to better ensure
quality. While providing checks and balances for the lowest denominator these
will also typically slow down the best.

This is especially nefarious when you consider that a "great" programmer can
be 10x (or more) as efficient as an average one. That's probably because they
developed habits that make them so, and now you risk meddling with those
habits. Making a 10x as efficient programmer 20% less productive can be
costly.

The most insidious thing about this as top performers typically can stomach
only so much "crap" that slow them down before leaving for another job. Which
leaves the organisation with even less skilled workers that need even more
"overhead" to control which in turn results in even more "good" employees
leaving. Iterate a couple of years and you have an organization where it is
very hard to do anything wrong but also almost impossible to get anything done
because of all the committee's, best practices, etc

Of course pair programming is going to slow the best programmers down without
adding much benefit. On the other hand for bad to average programmers pair
programming will probably result in better code with will offset the reduced
efficiency. From an organizational standpoint pair programming will reduce
dependency on any one programmer.

It's up to every company to decide which trade-offs they're willing to make
and balance that against the kind of employee's they have. Some lightweight
practices might actually be beneficial even for the top performers but they do
take some serious consideration to get right.

If you can manage it, hire really good developers and get out of their way.

~~~
skrebbel
your entire point is based on that 10x productivity rule. it keeps popping up.
Is it just someone's gut feeling turned into an urban myth or have real
studies been done?

~~~
mynameishere
The 10x comes from the fact that you have 10 fingers. The real number is going
to depend wildly upon the context. I've been on projects in which some members
contributed zero--and so the ratio is NaNx. On the other hand, if you're
writing COBOL crud, the fastest typist will typically be the most productive.

~~~
georgemcbay
I've been on projects (and I'm sure I'm not alone in this) in which some
members contributed negative value.

To contribute zero a bad programmer would have to just sit around and reddit
all day or whatever. Once the bad programmer starts writing code he is almost
surely a net negative since eventually someone is going to have to rewrite his
code and unless the code is completely decoupled from everything else, the
time required to do that rewrite will exceed the time it would have taken if
the bad programmer had never written any code at all.

------
lukev
Off topic, but the "considered harmful" titling meme annoys me. Dijkstra gets
a pass, but it's now become a passive, cliched, content-free, overused way to
say you disagree with something.

~~~
zeeed
logging in to upvote parent. to me, tc has lost its journalistic credibility a
while ago.

~~~
tincholio
>tc has lost its journalistic credibility a while ago.

Around the time it was founded, I'd say

------
suresk
I really dislike paired programming, and if I ever end up in another situation
where all or most of the day is spent sharing the keyboard with another
developer, I think I'd go insane. My first experience with it [1] was pretty
bad from both a happiness and productivity perspective.

I've always thought that for the purpose of improving code quality and
transferring knowledge, a formal code review process is much, much better.
Indeed, I've always wished more development shops would utilize a code review
process of some sort.

1\. [http://www.spenceruresk.com/2009/03/impaired-programming-
how...](http://www.spenceruresk.com/2009/03/impaired-programming-how-neither-
of-us-is-as-dumb-as-both-of-us/)

~~~
pmjordan
I find pair programming is useful for overcoming a _specific_ problem, after
which you have to disband and each go off on your own. Examples:

\- The problem can be that programmer A is stuck on a piece of code or
debugging: this is usually part of a bigger task which A has as the top thing
in their mind, but for some reason can't make progress. Programmer B brings a
fresh pair of eyes to the table, but looking at it alone makes no sense,
because their mental model will be up and running much faster with A's help.

\- Onboarding. Programmer B is new to the project and programmer A gives an
increasingly hands-on crash course of the project workflow and B's first task.

\- The high-level parts of major refactorings. Neither A nor B will have the
whole existing structure of the code completely in their heads, but between
them they have a more complete picture and stand a much better chance of not
messing it up.

None of these should take more than a few hours, or maybe a day max, or you
probably will go insane, yes. It probably also depends on personality, but you
should hopefully not have any homicidal tendencies after just a few hours.

~~~
suresk
Sorry, I should have worded that a little more carefully. Yes, I agree there
are situations where a limited-duration pairing is useful and even ideal.

It is only when pairing consumes most of your day for days or weeks on end
that it gets really tiring and counter-productive.

~~~
pmjordan
FWIW, I agree with you about code reviews. I'd add that I've found in-person
code reviews to be the most helpful from a communication point of view. For
remote teams I suspect live screen sharing with audio is a reasonable
substitute. I guess the downside compared to a formal annotated code review is
that the latter is a kind of documentation. Not that I've ever referred back
to one, but it's conceivable.

------
trustfundbaby
I have always found the idea of pair programming odd, because to wit, I don't
know any other intellectually involved/creative endeavor that forces people to
work in pairs like this. Even more fascinating is the absolute lack of data to
show that pair programming does indeed improve group productivity (unless I
missed it, please send me links if I have)

On a personal level, I absolutely detest the very idea of _fulltime_ pair
programming, but I assume that its because of my personality. I hate it so
much that when I was interviewing for gigs, the first thing I would ask is if
they pair programmed, if they did, I'd politely remove myself from the running
for that position with the company.

I have my moods, sometimes I want to work for 18hrs straight, sometimes, not
so much. Sometimes I want to go down a rabbit hole that I know is stupid, I
just want to because its exciting to try out possibilities. I hate that pair
programming would seem to preclude all that (again I might be wrong).

I don't want to constantly be explaining why I'm doing something, it just
seems tiring. It takes something I enjoy and turns it into 'work', where I'm
just coding with someone, day in day out 8 hours a day. Good for the company I
suppose.

I'm sure people love it though, what would be an interesting statistic to see
is how many devs would pair program if they didn't have to.

~~~
cageface
_I don't want to constantly be explaining why I'm doing something, it just
seems tiring._

This is my biggest objection to pairing. Usually when I'm first working on
something new I don't really understand the problem so I'll slap together a
very quick & dirty solution and then either refine it from there or toss it
and start over. Being forced to slow down and verbalize my thought process at
this stage just slows the process way down and makes me less willing to
experiment.

Good code reviews seem to me to provide most of the upside of pair programming
with none of the downside.

~~~
heretohelp
>Good code reviews seem to me to provide most of the upside of pair
programming with none of the downside.

Your suspicions are accurate. I can't find it right now, but I remember
reading a thorough study on software and the bugs eliminated by various
processes. It was code reviews (multiple variations of them, in fact) that
stood head and shoulders above the rest in preventing bugs from reaching
production.

------
MatthewPhillips
Looking at a specific problem for a short period of time (10 minutes) with
another competent programmer is one thing. But trying to concentrate with
another person looking over your shoulder is aggravating. My experience is
that you are more likely to take shortcuts to get the task over with. You
don't want to do anything that is going to take real concentration because
concentration is impossible when another person is likely to interrupt your
thinking to converse. That is by far the worst part of pair programming.

Knowing that your mind is free to explore a problem to whatever depth is
necessary is _absolutely critical_ to solving something non-trivial.

I find it really hard to explain the damage of interruption to non-
programmers. Whether it is a girlfriend or a client that likes to talk while
you're fixing their bugs. I don't think it is necessarily unique to our
profession, but it is certainly rare enough that most people seem not to get
it.

------
pmjordan
The headline doesn't really reflect the article, though after all its waffling
before getting to the point I don't think any of its conclusions are all that
revolutionary. It comes down to this: when developing software in a team[1],
you have conflicting requirements. Your programmers/designers need to
communicate effectively enough with each other[2] to keep them pulling in the
same direction, but you want to optimise individual productivity. The optimal
balance will depend on the project, team size and of course the individuals
involved. It will even fluctuate wildly throughout the project. So really, the
best thing you can aim for is to create an environment that's flexible enough
to adjust to a balance that is close enough to the optimum of the day.

I'm disappointed anyone _still_ believes any of these Methodologies with a
capital M will fix their project. All the techniques mentioned should be part
of the toolbox, but it's up to common sense to use them appropriately. _There
is no substitute for common sense._

Still, I was pleasantly surprised after my considerable initial trepidation
about reading a _programming_ article on TechCrunch.

[1] or probably doing anything else creative, but I can't speak from
experience

[2] and, let's not forget, communicate with the actual users of the software

------
dinkumthinkum
This is definitely YMMV territory. On the whole, I think a formal pair
programming process is probably a bad idea. I wouldn't want to work somewhere
where I had to play that game. Perhaps, that just means I would be a poor
choice for such a company. :) However, I wonder how many of the "great"
who's-who of programmers would have actually liked such a process; sure, you
can find some examples, probably, but I doubt many. It's probably a
personality thing. If two people are so in sync that they can code without
slowing each other down or getting in the way of each other thinking through
complex ideas then they probably should be pair programming, but I just wonder
how much of that really exists.

I think many of us program at our best with a little solitude. Now, I do think
"pair programming" can be beneficial with solving a particular problem but
this is like something everyone should know just from life.

------
greenyoda
This article begins with the premise that Atul Gawande's insights may apply to
programmers. However, Gawande's writing has dealt mostly with the work of
people like surgeons (he's one) and airline pilots. There's a crucial
difference between this kind of work and the work programmers do: surgeons and
pilots have to get everything right in real time -- a very brief lapse in
attention could lead to disastrous consequences. Programming is different: you
can review code after it's been written and get the benefits of a second pair
of eyes (or several extra pairs of eyes) examining it at leisure. So if pair
programming makes a particular programmer more productive, that's fine, but if
it makes other programmers less productive, no tragedy will result if they use
code reviews instead.

That said, one of the major techniques that Gawande advocates is the use of
checklists, which can be useful even to programmers working alone to make sure
they haven't missed some important step (e.g., verifying that their code works
against a live server, vs. just passing unit tests). His article in the New
Yorker on checklists is interesting in its own right:

[http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...](http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all)

------
Keithamus
One thing which the article didn't highlight, which I discovered when our team
tried to switch to a 100% pair environment - the variable skill and speed of
individuals.

One of the biggest problems we had was developers getting frustrated inside
their pairs, because one of the members of the pair was weaker in some way,
either slower, less experienced at the product, or less skilled generally.

Not only this but in a diverse environment with multiple cultures, where
various disciplines vary, it managed to increase stress levels a lot also (as
an anecdotal example, one of our colleagues was wound tightly and liked to be
very procedural, while the rest of us were very laid back). These people all
worked great on their own -- and got along -- but as soon as you pair them it
all goes to shit.

------
Jach
The only account of pair programming that made me spend time considering it
was the story of Guy Steele pairing with Richard Stallman. My overall takeaway
is to treat pairing like mind melding, and if you can't get your minds to meld
it's going to be disastrous. From
<http://oreilly.com/openbook/freedom/ch06.html> :

"We sat down one morning," recalls Steele. "I was at the keyboard, and he was
at my elbow," says Steele. "He was perfectly willing to let me type, but he
was also telling me what to type.

The programming session lasted 10 hours. Throughout that entire time, Steele
says, neither he nor Stallman took a break or made any small talk. By the end
of the session, they had managed to hack the pretty print source code to just
under 100 lines. "My fingers were on the keyboard the whole time," Steele
recalls, "but it felt like both of our ideas were flowing onto the screen. He
told me what to type, and I typed it."

The length of the session revealed itself when Steele finally left the AI Lab.
Standing outside the building at 545 Tech Square, he was surprised to find
himself surrounded by nighttime darkness. As a programmer, Steele was used to
marathon coding sessions. Still, something about this session was different.
Working with Stallman had forced Steele to block out all external stimuli and
focus his entire mental energies on the task at hand. Looking back, Steele
says he found the Stallman mind-meld both exhilarating and scary at the same
time. "My first thought afterward was: it was a great experience, very
intense, and that I never wanted to do it again in my life."

------
dustineichler
This [redacted] pisses me off, I'm sorry. Jon writes well, but I read the New
Yorker article on "Group Think" which he references... in TechCrunch. I'm as
shocked as you are. It's speaks well of individual creative process and how
brainstorming and really other processes are bull crap. Technically speaking.
If you think back, before Agile and other methodologies came along, developers
were doing more with less than I'd consider any of us are doing now. For the
most part. Pairing works, no doubt but I _hate_ how institutionalized it's
become. I'd work at Pivotal if I could, but they pair 100% of the time. I
consider myself an introvert, for the most part too. Pairing is painful if
it's not organic. The article is inconsiderate article because it's speaks
nothing to the fact that our profession was built on the backs of people who
are socially awkward and enjoy privacy if not a certain level of autonomy.

------
pairing
I pair 100 percent of the day so 8 hours a day for the last year. It has been
a very rewarding process. As a natural introvert pairing has made me a much
more communicative person and my programming ability has significantly leveled
up as well.

We pair with 2 monitors, 2 keyboards, and 2 mice facing each other with our
own desks which I feel gives each person in the pair enough privacy and space
to make us both very comfortable.

Is pairing intense? Yep. Is it worth it? Absolutely in my mind. The high
quality of the code and the productivity is well worth it.

~~~
pmjordan
Do the screens display the same content, and do the input devices control the
same cursor? I find this 2-desk pair programming a curious arrangement.

~~~
pairing
Exactly, one monitor is an iMac the other is a thunderbolt display. The
display just mirrors the iMac. We each have our own keyboard and mouse which
controls a single cursor. The monitors face opposite each other so we are
sitting (almost) directly face to face so talking to each other is natural
with minimal turning, which would occur if you sat next to each other.

~~~
pmjordan
Interesting. I have a feeling this would drive me insane in the long run. Is
there a particular problem you're attacking with this arrangement? Did you try
a different approach before that didn't work so well?

------
ralphos
I think the conclusion he has is right. It's not appropriate to pair 100% of
the time. Having said that if you look at the way Pivotal labs pair up, they
have really strict rules about what's allowed on the 'floor' e.g. No laptops,
no cellphones, no distractions. So while working alone can give you more
privacy and space to become creative, unless you're really disciplined by
yourself, pairing up can actually be beneficial in forcing you to become more
productive.

I think the other thing the author fails to mention is that in terms of up-
skilling developers, the process of pairing is quite useful. Often the pairing
will naturally raise the level of the weaker programmer by virtue of being
exposed to new ideas and solutions by the more experienced developer.

------
jackfoxy
_two coders at one keyboard..._

Pair programming without dual keyboards and mice deserves castigation.

~~~
derekp7
Is there any good way to have two keyboards, two mice, both act semi
independently? That is, I want two mouse pointers, and if mouse A clicks on a
window, I want keyboard A bound to that same window; same with mouse B and
keyboard B (and of course they can also each click on and be bound to the same
window as needed). Preferably a Linux solution, but something on Windows would
be OK also.

What often happens, is someone would ask me to help them look at something,
but they are multitasking multiple problems. Initially I can take over their
keyboard & screen, but before long another call comes up and I have to
transfer the problem / environment back to my desk, and get back to them (or
end up owning the problem completely).

I think having the keyboard & pointer independence combined with an editor
that lets you have multiple windows attached to the same edit buffer (like
Emacs) would be wonderful.

~~~
dustineichler
You could try mirroring monitors.

~~~
derekp7
But in that case, both monitors are still tied to the same workspace, and only
one window can be active at a time. I'm looking for a way to have two active
windows, each with its own keyboard attached.

~~~
dustineichler
This might be worth a read. Tom Dale wrote about his setup. There's a
reference to how Pivotal Labs is setup too. I prefer the later if you can
afford it.

<http://tomdale.net/2012/01/tildes-pairing-setup/>

