
Where Pair Programming Fails for Me - tenderlove
http://tersesystems.com/2010/12/29/where-pair-programming-fails-for-me
======
blatherard
This guy describes a really common antipattern I've seen with pair-
programmers, call it "Workstation Chain Gang". This is where _all_ work is
done sitting side-by-side at a computer, and the only times you get up are for
the bathroom or eating.

The best pair programmers I've worked with will often do things like: say
"let's take a walk" and then talk through design problems, get up and use a
whiteboard, say "I want to read about this. Let's get back together in half an
hour." Or even say, "I need some alone time" They attend to their own needs
along with the needs of their pair. This can take a lot of personal courage
and honesty sometimes, and requires an environment that encourages attending
to yourself.

This guy sounds like he felt like he needed to put on a continuous show for
his partner, and that was really hard for him. Which it is!

I bet he was right that he had to be constantly chained to the workstation.
The "eight-week sprint" sounds like a pretty awful slog, especially with the
set-in-stone up-front design. Overall, it sounded like a lousy, poorly managed
setup.

Its too bad that he associated it with pair programming particularly, but oh
well. There's many ways of working in the world, and it sounds like he's
happier now.

~~~
harringf
> "let's take a walk" and then talk through design problems.

That is the MOST important part and yet every single training fails t mention
this.

------
DanielRibeiro
I've pair programmed quite sucessfuly for several years. However, it is a very
hard practice. It requires trust between people, first and foremost. Besides
that, it requires knowledge that you can't do it all day. It is too intense
and tiresome, and this lack of slack is bad for creative thinking. About the
pride: it is like co-foundind a startup, where you build something toguether
with other people (it is all yours).

Some other links:

\- Dijkstra Pair Programming: <http://c2.com/cgi/wiki?DijkstraPairProgramming>

\- Some notes on Pair Programming <http://wp.me/puh71-1y>

\- How Pair Programming Really Works: <http://bit.ly/5oOd4C>

\- Why I Don't Like Pair Programming (and Why I Left Pivotal):
[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)

\- The real motivation behind pair programming: <http://bit.ly/9DNurb>

------
geophile
What a fucking nightmare.

Whether what he did was or was not Official Pair Programming (tm) is beside
the point. Obviously, some people will thrive having to interact with a
partner all day, every day, while others will wither. Requiring all your
developers to work in this style is just nuts. It's like requiring all your
developers to wear size 31 jeans.

~~~
aaronblohowiak
I don't think it is nuts if it is clear in your hiring process. Grockit has
you pair for a day for your interview (or they did a few years ago) so you can
experience what it is like, and see if you are a good fit. I agree that
surprising people with pairing or trying to mandate it on an existing team is
unwise, but building a company upon an ethos (to the exclusion of certain
personality types) is a reasonable decision.

------
nphase
"And if I was writing code, I found something very interesting: I don’t think
in English when I write code. I think in code first, and I can translate
written code to English. When I was trying to talk to people when I was
writing code, I found that I’d have to write pseudocode and then talk to them
about it -- and when my pair wanted me to talk about code, he wanted me to
stop typing. But if I stopped typing, I couldn’t describe what I was doing.
_Every time I tried to write code and talk to my partner at the same time, I
could feel the lurch between what I could feel -- the complex shape of it in
my head -- and what I was having to say._ "

(emphasis mine). What an incredibly familiar description. Does anyone else
ever feel this way? This is why in situations where I'm trying to describe a
solution I end up just grabbing the keyboard, doing it myself, and letting the
code talk for itself.

For me, pair programming comes easily when describing a solution that can be
simply defined and understood. Doesn't matter how difficult the problem itself
is. Pair programming becomes more difficult once you have to interrupt your
coding to facilitate the process. As an introvert, this comes incredibly
unnaturally to me.

~~~
cowpewter
Yes, that does sound familiar. I've never done pair programming, but I have
the feeling I'd have a lot of the same problems as the OP. I'm very much an
introvert, and even just our open-plan office sometimes has me wanting to shut
myself away by the end of the day. And the more code I write, the less English
I seem to speak, especially to describe code. I wind up either flailing my
arms and speaking gibberish (only a mild exaggeration) or just giving up and
writing pseudo-code because I just _can't_ express the concept any other way.
English just isn't _precise_ enough.

------
mkramlich
Great article. I like to see people giving a detailed critical response about
a practice which has increasingly become a kind of "Politically Correct"
element in software development. Must always write units tests, for
everything, and first -- hallelujah! Must pair program -- praise be thy name,
thou art in heaven!

My own take: if it works well, do it. If it doesn't, do something else.
Repeat. But your bottlenecks in the larger world tend to be talent, time and
cash (though the latter is becoming less so in software development). If you
have (enough of) those, use them and ship, get profitable, and anything
procedural or paradigmatic should be far down your list of priorities.

------
billmcneale
This matches my experience as well.

Like most things advocated by XP people, pair programming is simply soul
crushing and meant to replace skill and experience ("I know it's not the
simplest thing that could possibly work but my experience tells me we'll be
needing this later") with mindless repetition.

Very much like religion.

Thanks, but no thanks.

------
ludicast
I hate pair programming. I find a lot of the times my partners are distracting
me with a forgotten semicolon while I have already added that to my queue
while my fingers are racing along.

On the other hand having to justify an idea to someone else (provided they are
non-contentious, but really trying to analyze things) is worth its weight in
gold.

In short. pair programming only works for me if I am surrounded by "yes men".

------
wccrawford
I got to the point where the other person started typing when it wasn't their
turn.

First, pair programming has to be between near-equals, or it just doesn't
work. If one person knows a lot more than the other, most of the time is spent
in training.

Second, if the other person just starts typing, it isn't really pair
programming. It's what we call 'peer programming' where you peer over
someone's shoulder and they do all the work.

'Peer programming' happens a lot with mis-matched skill levels.

I didn't read the rest, but I assume it's all as much a bastardization of Pair
Programming as the first bit.

PP didn't fail you. Your coworkers weren't using it.

~~~
gnaritas
> First, pair programming has to be between near-equals, or it just doesn't
> work.

That depends on what you think the goal of pair programming is.

> If one person knows a lot more than the other, most of the time is spent in
> training.

Which is part of the intended effect of pair programming. It forces everyone
to share their knowledge with everyone else both about programming, and about
the code base. This brings new people up to speed quicker, allows the more
experience to better share their knowledge, and protects the company from
having too much knowledge locked up in one individual.

~~~
hammerdr
I agree.

To the GP's point though, they still weren't doing effective pairing for the
'training' or 'coaching' scenario. The pairing was contentious and out of
balance. The coach didn't do any coaching.

> ...if I paused too long, or seemed to be typing the wrong thing -- my pair
> had another keyboard, and he would type over me to try to “finish the
> sentence” rather than talk to me.

In this case, a coach should engage the driver. Ask about what he's thinking
and nudge him in the correct direction if needed. Coaching is a lot like
driving school. The coach uses his brakes (keyboard) very seldom. If the coach
_is_ using his brakes very often, it is as likely as not that the coach is the
problem (too scared, poor instruction, etc) and not the driver.

There are simple tricks. I usually put my keyboard behind the monitor. I've
also turned my keyboard around so that I'm looking at the keys upside down.
Those both take physical effort to get the keyboard in position to type.
Another strategy that I've heard is oven mitts (I really want to try this
one!) :)

Edit: Also, another strike against his coach (though this is more programming
related..)

> To me, this was “refactor mercilessly” and “once and only once.” But to my
> partner, this was a violation of “do the simplest thing that could possibly
> work.”

I'd agree with the OP here. Simplest thing is how you get tests to pass.
DRYness is a property of code quality. They are orthogonal. Refactor
mercilessly when you have green tests in order to keep quality high. Do the
simplest thing when you have a red test in order to deliver features.

~~~
gnaritas
> Simplest thing is how you get tests to pass. DRYness is a property of code
> quality. They are orthogonal. Refactor mercilessly when you have green tests
> in order to keep quality high.

And once tests are passing, you should be able to convince your partner the
code isn't dry simply by pointing out duplication, preferably 3 or 4 instances
of it so you have enough examples to generalize a solution. You don't need
tests to convince him something needs done.

------
bkz
My view is that pair-programming is a tool which only really works for stuff
dealing with tactical decision making, logic/fact checking, teaching or
debugging.

Higher level abstract stuff which involves creativity (design) or strategic
decisions won't work because there is no process for these activities. You
can't synchronize (communicate) where you are on your way to the "eureka"
moment. Discussing with others certainly helps but there nothing pair-
programming specific about it.

Also, don't forget that most, if not all, of the assumed benefits of pair-
programming can be gained using a more flexible common sense approach:

Reducing defects? Code-reviews.

Over engineering? Design documents.

New hires? People switching projects? Assign a mentor for a week or so and
have them pair-program.

Faster debugging? Understand that it is OK to ask a colleague for help.

~~~
sofuture
I didn't even know people pair programmed full-time. It sounds... awful.

My idea of pair programming is a ~monthly "Hey coworker, you want to do
sitdown this afternoon and figure out (in code) this bug/feature/design?"

Doing it fulltime sounds inflexible and impractical.

------
palehose
I don't have any experience with Pair Programming as it is typically
prescribed by "agile" project managers, but from my understanding of Pair
Programming, I believe that there are more cases like this where Pair
Programming doesn't work than there are cases where it does work.

I've also run into a fundamentally flawed hiring scheme at every company that
uses Ruby on Rails in which I am flat out not considered if I do not have
experience working on an "agile" team doing every day pair programming. There
are a lot of job descriptions that back this issue up.

I learned Ruby on Rails on my own and have successfully developed and deployed
two significant applications during my spare time using Ruby on Rails in the
last 3 years. The applications I've written are not open source and they are
not public access sites, and until I do get something written within the
public facing / open source realm, I am convinced that I probably won't ever
get considered for a full time rails job.

I've mostly just about given up on ever expecting to get hired by a company
that uses Ruby on Rails. It is all total bullshit in my opinion. I will
continue to use Ruby on Rails on my own and ignore Pair Programming because I
see Pair Programming as a form of micromanagement and not an opportunity for
programming productivity.

I have plenty of experience working with other software developers on the same
piece of code, in front of the same terminal window, for two or three hours at
a time - always initiated by myself or the other developer, not prescribed by
management. The fact that I don't do it every day is irrelevant in my opinion.

~~~
aaronblohowiak
"I've also run into a fundamentally flawed hiring scheme at every company that
uses Ruby on Rails in which I am flat out not considered if I do not have
experience working on an "agile" team doing every day pair programming."

This sounds like sample error. It is true that RoR culture overlaps with pair
programming/XP culture and agile culture, but there are VERY MANY RoR places
that do _not_ pair every day.

------
dgreensp
No one should have to suffer what this particular man suffered. Holy crap
that's depressing.

~~~
ams6110
His experiences with pair programming parallel my own. I had to quit an
otherwise fun job, that paid really well, because I simply could not stand
being that close to other people for that much of the day.

------
sniW
After a few months of pair programming, I can only agree. At points, when my
partner saw a better way of doing things, it was insightful. In the end,
however, we found that it was more efficient to split up the work, merging
code when necessary.

------
StudyAnimal
I generally like pair programming in some cases, and dislike it in others.

You have to combine it with TDD or else each person focuses on something
different, and basically reverts to being a spelling mistake checker until it
is their turn.

I have only enjoyed it when doing mostly new development, in a modern language
with modern tools, combined with a strict red green refactor process, where
one person writes the test , and the next makes it pass and writes the next
test.

For more exploratory stuff, or doing it without TDD, or using old crappy
languages and tools, or doing maintenance, it just sucks and I prefer to work
alone.

------
sandGorgon
In my place, I sort of enforce pair-programming for about 2 weeks before a
deadline. Basically at crunch time.

I basically believe that crunch time increases the probability of errors by
orders of magnitude. Secondly, as the author mentions, that is the time when
gaps in knowledge need to bridged over... at the expense of personal ego if
need be.

~~~
billmcneale
> In my place, I sort of enforce pair-programming for about 2 weeks before a
> deadline. Basically at crunch time. I basically believe that crunch time
> increases the probability of errors by orders of magnitude.

Code reviews will give you the same benefits without the soul crushing
drawbacks described in the article.

~~~
sandGorgon
For a short, intense period of time - pair programming can produce the same
benefit as code + code review, without taking as much time.

Plus code review has an inherent context switch (for the reviewer) that is
even worse during a crunch time.

~~~
billmcneale
I did code reviews at Google for four years and it never felt like a burden,
more like a part of my job that feels gratifying and useful. I also loved
knowing that every single line of code I wrote was going to be reviewed.

Pair programming is not used at all at Google, mostly for all the bad reasons
cited in the article. And also because code reviews really do work
(admittedly, Google has a fantastic infrastructure to support it).

------
joevandyk
I think the author is conflating Pair Programming with other concepts.

 _There are no high notes, no thought out design. There’s only the design that
could have tests written for it, in the time you had to write the tests. The
classes look reasonable at first glance, and the methods are seemingly bug
free. But the cracks are there, if you know where to look._ ...

 _Eventually, I realized that many of my partners had never worked outside a
test driven development process: they didn’t have the same idea of design or
architecture as patterns distinct from code. Trying to argue for encapsulation
or adherence to SOLID principles is pointless if your partner has no
background, let alone hands on experience, with what you’re saying. This goes
double when you’re talking about hard-won domain expertise: the more I knew
about a subject, the less I could say._ ...

 _The large part of pair programming was doing things in “The Simplest
Possible Way That Could Work.” In practice, this meant doing it the way that
it had been done previously, with the least possible amount of change._ ...

What on earth does any of that have to do with Pair Programming?

~~~
will_sargent
> What on earth does any of that have to do with Pair Programming?

I'm the OP.

What I'm describing is my experience Pair Programming in one organization, and
why it didn't work for me. To tell the story, I needed to provide the context
and the background to say why it didn't work for me. They're distinct issues,
but the only way we could relate to those issues and work through them was
through the lens of pair programming.

Keep in mind that I'm not trying to say that Pair Programming is a flawed
practice in principle, or even that their approach was flawed _in practice_
for the company -- there are other metrics besides code quality that a startup
needs to consider if it's going to survive, and sometimes "good enough" code
is good enough.

I'm well aware that pair programming works very well for some people, and that
my experience may not be typical. However, just because my experience wasn't
typical doesn't mean it didn't happen.

------
spooneybarger
I've had good experiences with pair programming. This does not sound like my
experiences and I feel for the writer. It sounds like a horrible situation to
have lived through.

------
steveklabnik
Sometimes I feel like I'm the only person that enjoys pairing way more than
coding by myself. :/

~~~
glhaynes
I think of it kind of like romantic relationships. If you're paired with the
right person, it's bliss beyond bliss. If you're not...

