
Why Pair Programming Is Not For the Masses - fogus
http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html
======
gcv
I had fairly bad experiences with pair programming. None of the physical
reasons the author brought up applied: it was in a decent, private room, with
decent hardware. The social problems did not apply: it was with cool, friendly
people.

It turns out that, in pair programming, while the active person hacks with all
his neurons firing, the passive one sits bored out of his mind. I found that
passively following someone else's programming, and possibly even fixing minor
mistakes, barely uses up a fraction of the mental energy of actively coding.
The passive ends up being a distraction. When the passive makes a comment
("have you considered changing this function to do XYZ?"), the active looks
up, completely distracted and torn from his concentration, and stares at the
passive. "What?.. What did you say?.. Oh... yes, that function... I already
thought of that, and here's why it can't work." Basically, I found that being
passive in a programming pair also blocks the kind of forward-thinking
analysis which leads to good programs.

One more thing. The author claims that pair programming helps avoid duct-
taping problems. I completely disagree, at least when it comes to my own work.
When I look at my code, and I see the beginnings of something bad, I ask
myself: "Could someone else understand this in two months? Will I, when it
breaks?" Then I go back and fix it. Whereas in pair programming, two people
will likely look at each other and say, "Oh yeah, that's an obvious
workaround! Let's keep going!"

~~~
keyist
Some replies to your comment demonstrate exactly why I'm not a fan of forced
pairing advocacy and the arguments they use. It borders on the religious: "I
love pair programming. Try it, you will love it too"

When someone doesn't experience the unbridled joy of pair programming
salvation, it is _always_ something wrong with them, their task, or their
partner. Essentially, "oh you weren't pairing correctly" -> "you didn't have
enough faith".

Is there any possibility pair programming advocates can cede that developers
can eschew pair programming and still produce quality code?

~~~
mbrubeck
Since I wrote one of the "here's how you could fix your pair programming"
replies, I should clarify that I don't think pair programming is the only way
to work. I'm not doing it in my job right now and don't particularly think I
should be.

If you are pair programming either by choice or circumstance, it's useful to
know some tricks to make it work better. But if you've tried it and don't
think it's the right thing, then you should do something else.

------
mhd
Wow, that's one arrogant piece of writing. That still doesn't provide any
good, scientific reason why pair programming is that much better -- yay for
anecdotes.

But I guess I'm just one of those anti-social programmers. Excuse me while I
try to see which of my unwashed heavy metal shirts to wear today.

~~~
davidalln
I too certainly got this holier-than-thou sense from reading the article, and
I also felt that it missed the point.

Pair programming doesn't work for everyone not because of those pretty dumb
reasons. Pair programming doesn't work for everyone because not everyone is
the same in their thought processes. Personally, I'm a very outgoing guy and
when working with a team on a problem I love to throw ideas around and, if I'm
the more knowledgeable one of the group, teach. But I know for sure that some
people would rather work alone on a problem, and if that's what gets a problem
done quicker and more efficiently, power to that person!

I was hoping this article would dive into the more social aspects of pair
programming, but nope. Instead it was "your hardware sucks" or "your company
sucks".

~~~
mhd
Apart from the fact that we're still missing a serious study of pair
programming (isolated from other Agile hooplah), it's also a false dichotomy.
Isolated damsel programmer in the ivory cubicle vs. paired mind meld.

I would say "Pair programming? Yo, Obie, I already gotta pair!" in my best
Andrew Dice Clay manner -- but with a German accent, my best Andrew Dice Clay
manner is rather abysmal...

~~~
jamesbritt
"but with a German accent, my best Andrew Dice Clay manner is rather
abysmal..."

Hmm. Andrew "Würfel" Klay could sound interesting ...

------
myth_drannon
"I find it best when I put a guard with a whip near each programmer. They work
faster , more eager to stay long hours, produce on average x2 more lines of
code. They should not forget that only 100 years ago their forefathers were
working 18 hours in Manchester assembly lines factories. They should know that
although it's a 21 century, the system has not changed"

------
Kirby
I, for one, get higher quality work done when I'm allowed to take breaks. This
shop might be heaven for workaholics, but there's a lot of really excellent
folks who just wouldn't enjoy their jobs if there was someone in the room
constantly pushing them to keep working. It's great their culture works for
some, but if this were the norm - I'd quit my job and go back to school in
something that didn't involve computers, very quickly.

Or go into management. Do they practice Pair Leadership? Didn't think so.

~~~
callmeed
Actually, if you read the NYT article, they use a pomodoro time management
technique–25 mins on, then a 5 min break.

<http://www.nytimes.com/2009/09/20/jobs/20pre.html>

working hard != being over-worked ... at least that's how I understood it

~~~
ismarc
The Pomodoro technique is phenomenal. I actually end up doing ~50 and 10
rather than ~25 and 5. The trick is, when the buzzer goes off, I hit save,
mash make && make test and go grab a cigarette. Chat about the weather, video
games, anything really with other folks (non-smokers are encouraged to take
"smoke breaks" outside, get some much needed sunlight and just relax out of
the cubicles). Come back in, look at compiler output or test results and
there's a list of things to start working on. If it all ran fine, continue
working.

Amazing how something so simple as "get up and away from your desk" does more
than any "agile", "extreme" or "You're kicked from a plane, you must write a
driver that interfaces the rip cord to the parachute release mechanism in
order to deploy your chute" methodology.

------
WilliamLP
I'm completely and utterly unconvinced that two brilliant programmers can
produce _more than twice_ their usual individual output together, versus just
consulting when they have an interesting question or a stumbling block.

If you got Linus Torvalds and Richard Stallman sharing one computer for their
working lives, would they really have produced _more_ than on two computers? I
seriously, seriously, doubt it.

~~~
cracki
i'll bet you measure output in [LoC / hour], don't you?

pairing means sharing thoughts, means thorough examination of thoughts, means
validated thoughts, means code based on good reasoning.

~~~
WilliamLP
Have you got much besides straw-manning what I'm saying and proof by personal
assertion?

------
garnet7
> Hashrocket is a boutique shop, so we can be very picky about who we hire.
> [snip] We've hired qualified interns, but we don't hire apprentice or
> junior-level folks.

What ever happened to hiring good people and training them?

~~~
obie
It's hard to do that on a client's dime, at least for me. (I know other
consultancies do it all the time and it disgusts me.)

~~~
boucher
Part of running a business is paying the associated costs. Training new
employees is an expected cost of running a business, so take it out of your
end. Doesn't seem like a particularly outrageous idea...

------
richcollins
It seems like pair programming is quite popular with consulting companies
(Hashrocket, Pivotal). You get to charge for the time of two developers
instead of just one.

I haven't heard of any startups that pair program.

As a humorous addendum, my wife was part of a conversation where Pivotal was
mentioned. She interjected, "Isn't that the company where they do couples
programming?"

~~~
caustic
You have spotted it. The whole Agile movement and its practices, like pair
programming, are driven and promoted by consultants who make money out of it.

EDIT Moreover, I am not sure whether the companies you mentioned really
practice pair programming or they use it as a marketing ploy to impress they
customers.

------
BigZaphod
Ugh. What a horrible article. I've done mandated pair programming in the past
and I've had good and bad experiences during that time - it depends a lot on
who your partner is and what the project is - there's no way it can be "the
one true answer" with so many variables. My opinion is that pair programming
is something that good developers do naturally when and for as long as is
required. Mandating it for all development sends the signal that you think
your programmers are too incompetent/stupid to trust on their own.

While I'm a big believer in object oriented programming, even I can admit it
isn't always a good fit for every job. Pair programming is no different.
Believing otherwise is just your religion showing.

~~~
bdmac97
I fail to see in that article where it advocates mandated pair programming...
In fact I think it does a pretty good job of pointing out when/where pair
programming does NOT work (i.e. many environments for the reasons listed). If
you happen to work in an environment not conducive to pair programming and
they force you to do it... well then...

------
varjag
Pair programming to me is a managerial gimmick to keep trench people in check,
like those timesheets with specifics down to five minutes. To make them look
over each others shoulder, and not surf the web. To address the near-universal
management suspicion that your employees slack on the company time.
(Disclaimer: yes I did read _that_ book about the (failed) Chrysler project
experience generalization to whole industry, so am familiar with the official
hype part).

Many people just like the way people normally work better. To do the job you
assigned as you see fit, to possess quiet minutes for thinking at will, and to
have full control and sole responsibility for what you do. There is time and
place for interactions, that's why people have code reviews, meetings,
brainstorming sessions, et cetera. If sitting on the degenerate case of
meeting of two throughout all your worktime is your thing, fine, do pair
programming. But as the author clearly says it is not for masses, although I
beg to differ about the actual reasons.

------
acg
Perhaps programming isn't really for the masses, many of these points just
describe traits in people that cause bad software to be written period.

The best teams are those who are passionate about getting software right:
they'll do whatever is needed to make their software work well. Whether that
is pair programming or not. Whether to pair depends on how work is organized,
it really requires episodes <http://c2.com/ppr/episodes.html> (or usually
called stories). Pairing is, for me at least, one tool in the toolbox. It is
particularly good on green-field projects I've found where there are a lot of
decisions to be made.

------
socratees
> "When doctors screw up (massively) they get sued. When (permanently
> employed) programmers screw up they get let-go, and they go find a new job,
> usually with more responsibility and a pay raise. There are no ramifications
> for software malpractice."

Seems like a mindless rant to me. We can always keep modify software as we
like. The same can't be said for a bridge or a human being on a operating
theater. What an absurd comparison to make.

------
harold
The rigidity of this approach surprises me. I certainly think pair programming
has value. But I don't understand why this company would be so rigid in
enforcing it as the _only_ way to develop software.

~~~
plinkplonk
"The rigidity of this approach surprises me"

That is because you don't know Obie. HashRocket is Obie's vision about how sw
dev should be done made manifest. I would go crazy working at HR, but hey the
man has a right to his vision.

The interesting thing is how "agilists" who pride themselves on their , err,
agility are very rigid about "the right way to develop software".

------
steveklabnik
I've only ever had exceptional experiences when pair programming. Maybe it's
for reasons similar to Obie's; the people that I paired with were excellent
programmers.

If I tried to tell you why it was great, I'd basically be re-iterating what he
said. More focus, better code, less time, less bugs, better design...

------
Confusion
_To the average programmer, having to pair full-time means they won't get to
waste time during the day on [..] Hacker News._

If my employer wouldn't allow me to read HN during the day, then I'd go find
another one. Constantly learning and improving myself is what keeps me going
and HN helps me in that. I consider it my study time, which I otherwise don't
get (one of the major disadvantages of this employer).

------
ams6110
_Full-time pair programming keeps developers focused and coding, all day,
every day, week-in, week-out._

Sounds like a recipe for burn-out to me. Maybe if you switch to 6 hour days,
or 4 day weeks, it could be more sustainable.

I did like one thing he said though, which has nothing to do with pairing...
he said they require developers to purchase their own laptops. Like a mechanic
or carpenter provides his own tools. That makes some sense to me. Let people
chose the tools that they are most familiar with and most productive using.

~~~
duncanj
I think critics tend to compare pair programming to those moments when they
are most productive. One programmer in flow may be able to really crank
something cool out in a day or so. He might even work 25 hours straight to do
it, and really get it out there. If he spends the next week polishing,
tweaking, and adding very little functionality, he doesn't include that in his
comparison to pair programming. He did it in 25 hours, it took a pair of
programmers three days, the pairs are slower, even though the pairs are done
and have moved on to other, important stuff.

Pair programmers who work 6 hour days can finish a lot of useful functionality
in a week or two. They also have social lives, get to take long lunches, go
hiking on the weekends, etc., even though they are very productive. This is
why I prefer it. Plus, it's totally sustainable, and it comes with a built-in
training methodology.

I used to think that everyone really should start pairing. But I'm more in the
camp now that people should form little organizations that pair and basically
put everyone else out of business. If it's more productive, places like
hashrocket are going to become the leading shops for software. Their employees
are going to make twice the market rate, have social lives, good friends at
work, interesting problems to work on, and relativley low stress. If it's not
more productive, they'll probably eventually have trouble competing.

~~~
obie
Bravo!

The burnout objection is laughable. Our consultants are required to bill 35
hours per week, which translates to an average of 7 hours of coding or less
every day (there is billable work like meetings that is not writing production
code).

We don't work weekends and we don't do overtime. Like, ever.

~~~
run4yourlives
Only one form of burnout comes from long hours though. It can also come from
repetitive tasks that require little thought, or in your particular case,
being forced to approach problems in a rigid manner that isn't in your natural
style.

That being said, you've made it clear that your entire team already fits your
style, right down to having the same preferences in breath odour. I wonder
though how much productivity is lost managing that aspect of things. :-)

------
Flemlord
Pair programming is an attempt to take two good programmers and turn them into
one great programmer. If you hire great programmers in the first place, it is
unnecessary and wasteful.

~~~
jon_dahl
That depends on the difficult of what they're developing.

Boilerplate code? Two great programmers are a waste.

Moderate difficulty? Maybe less efficient than working separately, but they'll
still work a bit faster, produce fewer defects, transfer knowledge well, etc.

Really complex problem? Not a waste at all.

------
run4yourlives
_Being honestly hard-working is still one of the best ways to earn accolades
and raises. Accolades and raises usually bring some measure of added
happiness._

You know what I think produces better measures of added happiness? Not working
in a sweatshop.

My major problem with pair programming is that it has the effect of treating
programmers like children that need to be controlled. This is no different
than the corporate drone being assigned a single task to do over and over
again. It's more productive sure, but it's similarly a death march.

Sorry, but people aren't cogs in a machine. They goof off, they're
unmotivated, and sometimes - believe it or not - they do other things besides
work.

I'd much rather employ programmers in a traditional sense who are happy,
goofy, disagree a lot and are somewhat productive than have a super productive
team of like thinking robots, because essentially that's what you need to make
pair programming work.

Productivity is not the be all and end all.

------
ZeroGravitas
Depressing but accurate reading.

Even the standard "pairing sucks" advocates in the comments agree that these
things are what is stopping the average IT shop from being productive and
professional.

And, while as I say it's depressing, it also kind of makes me feel better to
know that most everybody else is in the same boat.

~~~
ams6110
I think pairing sucks. Based on my personal experience with it. I'm just not
cut out for it, mostly. I'm more comfortable and productive in the the
"private office with a door" environment that DeMarco and Spolsky advocate. I
don't dispute that pairing works for some people, in some situations.

Despite the overall "we're so smart and so much better than everyone else"
attitude in this piece, the still-relevant conclusion is that pairing is not
easy, requires large investments in both physical assets and people who want
to work that way. He even admits that once your team is larger than a dozen or
so, the feasibility of pairing starts to break down because of personality
conflicts.

~~~
ZeroGravitas
You've apparently been thrown off course by the love-it-or-loathe it reaction
to pairing, but you're actually _agreeing_ with the article. He's listing why
it _isn't_ feasible for most situations. (Though most people seem to interpret
this as reverse psychology, though I would suggest any appraisal of the
general practice of software development that doesn't portray it as almost
totally broken is far from accurate).

But really I could write a long (sometimes contradictory) list of things that
would help people program better that would get similar levels of reaction:

    
    
      * use vi
      * use emacs
      * use an IDE
      * TDD
      * unit testing
      * any kind of testing
      * writing documentation
      * using the highest level language possible
      * using C++
      * using anything but C++
      * source control
      * distributed source control
      * avoiding gotos
    

Judging by the _slightly over-emotional_ responses in this thread to pairing
you only need to find one good bit of software written without these
tools/ideas and you can ignore them totally. Apparently, in your case, an
individual not liking something, or it being hard, or requiring investment or
not being suitable for all sizes of teams rules it out, which covers most of
this list.

I would suggest doing hard things you don't like, which require investment and
need to be applied appropriately to your context is a pretty good definition
of "profesionalism", something sorely lacking in most software development
shops but on the other hand just because it fits that definition doesn't mean
it's the right thing to do.

I think that pairing, like many things in this list, can be appropriate and
useful but I'm not about to burn anyone as a witch if they don't like it or
practice it.

~~~
ams6110
Oh your reply just crystalized one of the main problems I had with pairing.
See, I use emacs and a bunch of command line tools. Almost everyone else in
the shop used visual studio. I think one other guy used some editor he liked.
So to pair with someone I had to use visual studio, which is like asking a
master carpenter to use a hammer and saw that were picked up at Wal-Mart
instead of the tools he had spent a decade mastering.

So in order to pair effectively, everyone has to use the same tools. And
that's going to be a big problem for people who don't like those tools. I
don't think the article really hit that point.

EDIT: Oh and your little aside: _I would suggest any appraisal of the general
practice of software development that doesn't portray it as almost totally
broken is far from accurate_ is fabulous. Love it.

------
wallflower
Pair programming works. However, I don't see the point in using it all the
time - in some situations, it's only as effective as working solo. It really
rocks for crisis situations (pair debugging) or new feature implementation
quickly (all-night coding).

Flow is a very important part of pair programming.

------
smokey_the_bear
I've tried pair programming a few times at several companies, and while it's
occasionally been great to work through a specific problem, in general I
wasn't a fan, it was awkward and boring. But recently, at my startup, I've
been sitting on the couch coding on the TV (because I switched over to iPhone
development and the only spare mac was the TV mac mini, and it can't drive my
30 inch monitor.) Pair programming has actually been happening fluidly with
this set up, and it's been great. It's comfortable to sit side by side and
both have a head-on view of the large monitor.

------
kscaldef
Let me get this straight. Did he just claim that managers need to be willing
to fire someone for having bad breath? And he has the nerve to accuse others
of tolerating anti-social behavior?

------
evilbit
pair programming went out of fashion for the same reason foosball tables in
the office did: it was a dumb idea somebody concocted in the haze of the
dotcom boom. reality eventually reasserted itself, we grew up, and learned to
work like professionals.

if the only way to keep your developers busy and not goofing off is to have
someone looking over their shoulder, then you, my misguided friend, fail as a
leader.

------
bdmac97
I just want to point out that saying "You're doing it wrong" (as the article
does) does not necessarily imply that you could be doing it right. It doesn't
have to be taken as a condemnation of your skills/ability. It simply won't
work in all situations and the article does a pretty good job of pointing out
blockers to pairing working.

------
yesimahuman
Pair programming seems like one of those necessary evils. I don't find working
with a partner any fun in terms of the joy of hacking stuff out and figuring
stuff out on your own, but I see the value in having multiple eyes on code,
and I'm sure it could have found lots of bugs in my past.

------
eplanit
Yes, arrogant and absurd. It does prove one thing (yet again). Beware of
Methodology Cults. That's what Agile and 'XP' are (who'd want to name a
methodology after a failed operating system, by the way).

Kent Beck = Jim Jones. Beware.

------
hcayless
Never really done pair programming, but I'm struck by how much it's culture-
dependent, and how easily it can be undone by initial assumptions. "We'll save
money on furniture." "That guy's good, but too expensive."

------
scotty79
From my experience on pair programming: \- it occurs naturally if you give two
programmers one computer and one problem. \- one programmer becomes
tactician/executor, other one becomes strategist/supervisor \- tactician
thinks how to make loop to iterate properly, strategists thinks why to make
loop and what to do next. \- it helps immensely to have someone who has
different ideas than you on your side, if you are willing to submit to this
ideas if you don't have other than idealistic arguments against them.

------
dagw
In my experience pair programming works best when used on hard problems. If
you're doing the sort of coding where there is no complex problem solving
involved and you're basically limited by your typing speed then pair
programming is probably just hindrance.

However for the sort of hard complex problem that is pushing you to your limit
and requires hours of thought, testing and prototyping to produce a dozen
lines of production code I find it can be enormously effective if paired with
the right sort of person.

------
cracki
that one guy at work, he either doesn't shower often enough for his type or he
never heard of deodorant.

as long as the wind blows away from him (windows open), that's not a bother
though.

edit: i thought i should share some of my pair programming experiences and
insights...

one time a friend and I programmed some ATmega embedded assignment for a
course. what happened was that we sat down on a couch in the library (our
faculty cares!), laptops on our laps.

and then the mind meld began...

i mostly talked about what i was writing at the moment, what considerations i
put into each call and conditional. reasoning out loud about various
conditions that could or could not happen. i did that so we were on the same
page and he would not hesitate to ask if anything was looking suspicious. the
resulting code felt very pure, i must say.

he had our plans, schematics and pinouts handy and kept track of the coding
progress (this done, that left). he knew how the parts would fit together and
steered the process.

i should pick his brain some more on that experience sometime.

the other time was at work, where a coworker got me to sit with him for my
experience with the python language. he went through that rushed job of
spaghetti while my eyes glazed over because i hadn't seen the code before.
occasionally i pulled on this and that dangling thread to see what was
attached, which gave me some insight and him some more things to fix (logic
bugs mostly).

that code still is buggy as hell (also because it interfaces with/works around
another buggy pile of shit), which is why i asked for a real code review. code
reviews are done rarely enough that i'm afraid it's gonna end without much
gain.

------
palehose
Why hasn't Pair Programming extended itself beyond just programming? What
about something like "Pair Accounting"? "Pair Book Writing"? I don't see
anyone arguing that the cubicle office is fundamentally flawed, except for in
cases where people are anti-social and don't like each other.

~~~
vsync
Then you haven't been reading much. I've seen tons of objections to cubicles,
some anecdotal and some based on scientific evidence such as noise levels and
interruptions from people walking by and chatting disrupting flow.

Even the guy that invented the cubicle hates it. His original idea was for a
workstation where you could do some work standing, some sitting, use 3d space
and not just 2d. I think we can all see how far from the original concept we
have come.

My objection to cubicles comes down to 2 things: Can't control lighting (and
offices always have those wretched overhead fluorescents) and there's always
that disconcerting feeling someone is standing there staring at you when you
essentially have your back to the whole room.

------
obecalp
Pair programming is good for UI/HCIish code and so so for other types of code.
Studies have shown that human are not good at multitasking even though it
makes them _feel_ productive.

Personally I think pair programming is overrated while code review is still
underrated.

------
yason
Pair programming bad. Pair debugging good.

------
wwkeyboard
From a quick, unscientific survey of the discussion around pair programming it
looks like most of the people who have tried pair programming like it, and
most of the people who haven't think it would suck. Is anyone else noticing
this pattern?

~~~
caustic
The article provides 10 reasons why pair programming might not work. Moreover,
it says that these reasons are very common:

    
    
      10. Most software managers...
      9. Most software shops...
      8. Most software shops...
      7. Most software shops...
      6. Most software people...
      5. Most software shops...
      4. Most software shops...
      3. Most software developers...
      2. Most software developers...
      1. Most software shops...
    

Do you see the pattern: most pair programming attempts, if they happen, fail,
because of "Most of the...".

You write: "most of the people who have tried pair programming like it". Your
conclusion is contrary to one of the the article.

------
tomjen2
Personally the idea of pair programming would suck out the joy of programming
for me. I just can't stand the thought of not thinking through what I am doing
and talking about it, is way slower than doing it in my head.

~~~
beza1e1
I think the point is to think-and-talk instead of think-and-rewrite.

~~~
gdee
Someone who is able to think and talk at the same speed is either an
impractically fast talker or an impractically slow thinker.

~~~
cracki
sacrifice "speed" for validated thought.

pair programming intends to _prevent_ rushed spaghetti code and replaces it
with deliberate code that was born from the shared thought of several people.

~~~
gdee
Spaghetti code is not necessarily the result of fast thinking... shallow is
enough... fast or slow.

However, fast thinking is necessary for playing out different versions of a
solution inside one's head and generally for analyzing the suitability and
elegance of one. That process is fast, internal and generally not conductive
of talking. Just concentration and discipline. Also, verbalizing a thinking
process is always a lossy compression. At least for me. And it's not because I
don't know how to express myself, although I might not be very good at that
either. It's because verbalizing a thinking process always feels like
serialization of an inherently parallel and _real time_ process. The mouth is
a shared resource here.

~~~
beza1e1
While you can evaluate elegance and simplicity in your head that doesn't work
for edge cases and side effects. That's were talking and writing and sketching
are helpful. I don't encounter much code where i can hack with the flow.
Mostly the task is either utterly boring or too complex for my little head.

------
c00p3r
Pair programing is not for everyone. Like any other method. Pair programing is
for motivated, enthusiastic and even addicted people. It is a different
approach to the problem, which people must have curiousness, motivation and
courage to try. Try together.

It cannot be forced or set up by the managers. It cannot be motivated by
money. It is for passionate people, who have a desire to solve some problem or
get things better together.

btw, Kent Beck's "Extreme Programming Explained" stats clear that it isn't a
silver bullet and it didn't work alone. Only together with testing, planing,
small changes and continuous integration. It is a part of collective effort.

And of course, passionate and enthusiastic people don't give a damn to things
like halitosis when they're doing together that they really love to do.

