

Pair Programming: The disadvantages of 100% pairing - kioub
http://www.javacodegeeks.com/2012/01/pair-programming-disadvantages-of-100.html

======
philwelch
I've found that while pairing is sometimes useful, it's often not. People,
even good programmers, have different brains that work differently, and that
sometimes gets in the way of pairing. You get into stupid arguments about the
right order in which to do things, or waste time bikeshedding about
variable/function names when really you just want to sketch the whole thing
out and clean it up later. And that's assuming no one ever mentally checks
out. If everyone pairs 100% of the time and you _don't_ have these problems,
what you probably have is a monoculture where no one thinks differently. And
if you do have those problems, you probably lose more productivity than you
gain from someone saying you forgot a semicolon.

The monoculture point deserves elaboration. The job postings for one
particular consultancy that does 100% pairing are pretty explicit about
requiring everyone to use the same particular text editor. Think of the five
or ten best programmers you know--do they all use the same text editor? People
say that their company has a "culture", and if you don't fit in then it
doesn't matter how brilliant you are. In other words, they place a higher
priority on being just like everyone else than they place on being good at
what they do. So already, they're handicapping themselves by not hiring the
best people. On top of that, they think they have a recipe for a "company
culture", but really what they have is a recipe for groupthink. Real cultures
have diversity. Healthy, creative cultures are the most diverse of all. So not
only are they not hiring the best people, but they're constructing a social
environment among the people they _do_ have that effectively makes them more
stupid.

100% pairing is probably one of the worst ways to develop this kind of
monoculture, because there's even a brain difference between people who
naturally are good at pairing and people who aren't. So not only are you
excluding the people who don't share your particular text editor and way of
thinking and working, but you're excluding those people within the already
exclusive population of developers who can pair effectively. And then you
complain that it's hard to hire people.

I went to a conference once where someone gave a talk about how awesome his
company culture was because they paired 100% of the time and after work they
went out to dinner or the bars together and talked about work and came back to
work to work on the ideas they thought about during dinner. Someone asked a
very insightful question about whether this culture excluded people who might
have had families, and they responded that everyone in their company were
young, single men. If I ran a company and I discovered that all of my
employees were bachelors with nothing better to do at night than hang out with
their coworkers and work some more, I would stay up at night worrying about
that. What about my company or my hiring practices is so broken that I only
hire people exactly like me?

One thing I've found enlightening to think about is that nearly all formal
methodological dogmas are promulgated by people who are selling something.
Who's going to make more noise--someone with some altruistic desire to advance
the state of software engineering, or salesmen? If you convince everyone
"agile" is a good idea, then maybe they'll want an agile consultant. If you're
going to sell scrum master training courses and certifications, you have to
sell the idea of scrum. If you're trying to sell CASE tools and you're not
clever enough to design software that can be adapted to different processes,
you need to sell people on using the process you designed the CASE tools
around. Likewise, if you're a consultancy trying to differentiate yourself
from all the other consultancies, you need to sell people on your process, and
pair programming is a process that conveniently allows you to double your
billable hours. That allows you to fully utilize all your devs on a smaller
number of projects, which reduces the overhead involved in bringing projects
onboard.

------
softbuilder
This pretty much nails it. Pairing is a tool in your toolbox. It's not
something you should be doing 100% of the time.

I did take issue with two points:

>I can certainly understand the argument that you should be learning things
like that in your own time anyway.

No! If you're using a new tool for work, work-time is when you should be
learning it. And learning in a pair can be great. It takes patience though.
Research, OTOH is harder. It's a lot like reading a book at the same time.
Often a strategy of "split-up and regroup later" works well.

>In my experience house cleaning tasks such as investigating why a test is
‘randomly’ failing on the CI machine are less likely to be looked at if
everyone on the team is pairing 100% of the time because it interferes with
productivity of a story.

You fix this by making those tasks their own, smaller story and throw a pair
on it. This is independent of pairing and is more closely tied to your overall
process. A granular system like kanban (which has its own problems) shines
here.

------
johnkchow
I have to agree that PP loses value when you have many senior level
programmers on the team. The biggest value in PP, in my personal experience,
is transfer of knowledge and experience. This applies mostly to teams with
huge gaps in experience (juniors vs. seniors) or new team members that need to
be caught up to speed with the codebase.

If the talent level is the same (and by talent I mean having the innate
passion and ability to learn, not having actual knowledge) the knowledge of
the collective team members will eventually equalize through the initial PP
sessions.

Like the author said, the context of the team and the general strategy of the
company (i.e. maintaining a project vs developing new features) are the most
important signals when determining the programming tactics (i.e. PP and self-
learning) to reach those goals.

P.S. The link at the bottom of the article
([http://blog.jayfields.com/2011/08/life-after-pair-
programmin...](http://blog.jayfields.com/2011/08/life-after-pair-
programming.html)), provides two great team contexts for when pair programming
succeeds and when it fails. Definitely take a read on that.

------
pavel_lishin
> You can’t just sit back and read some code. You can’t just sit and think. I
> mean, you can, but then your pair is just sitting there.

Or bugging you, breaking your train of thought.

