

Effective vs Ineffective Pair Programming - askorkin
http://www.skorks.com/2009/07/effective-vs-ineffective-pair-programming/

======
skolor
Having recently been exposed (by a class forcing us to use pair programming)
to this, I have a few insights on pair programming:

\- Both partners must be fairly versed in the language and methodology of the
programming. I think its fairly explanatory, but there is a definite limit to
how much of a knowledge gap there can be between the experienced and un-
experienced programmers. If that gap is too big the only result will be slower
coding, written at about the same quality as the more experienced programmer
would write on their own, but with considerably more frustration on both
programmers' parts.

\- Do not do a "test trial" of pair programming, working on simple projects.
From what I has read about research into pair programming, the only gains come
from working on complex problems which would be difficult to conceptualize
entirely in one person's head. If work is only done on small projects, pair
programming will look like a complete waste, since non-pair programming would
have similar results considerably faster.

\- Pair programming has a sort of half-life in terms of knowledge. The lower-
skilled of the pair will learn half the gap in knowledge at aproximately the
same rate. While that rate will be different between people, from my
experience with pair programming, the lower-skilled partner will learn half
the knowledge gap in 3-4 days. This will repeat, and the gap is halved every
3-4 days of working together.

On top of that, it seems to me that Pair Programming is not a good fit for
long term programming. It seems best suited when there is an individual who
needs to learn about a specific system, and that using it long term lessens
the effectiveness it has. Once the transfer of knowledge has slowed down, and
both individuals know aproximately the same ammount about the system, it seems
to be much less effective. However, since their (should be) a constant
learning about the system, occasional pair programming sessions would be
advantageous after this point.

If I were to engage in pair programming, this is roughly how I would set it
up:

Assuming that there a 5, 8-hour work days, divided into 2 4-hour programming
sessions (for a total of 10 sessions a week), when a new individual is
introduced they should spend the majority of their time pair programming with
the more advanced individuals. While I am just pulling this number out of thin
air, I would think 8 sessions of pair programming the first 1-2 weeks, with 2
sessions programming alone. As time progresses, I would shift to steadily less
pair programming, with a minimum of 2-3 sessions per week.

This is largely because I am not convinced Pair Programming leads to better
coding. I have not seen any real evidence to support that, in fact, from what
I have seen it tends to slightly more convoluted and difficult to debug code
(although pair-debugging seems to be incredibly effective). I have, however,
seen how useful pair programming is in teaching a person. The ammount a person
can learn in a short time, while working in a pair is incredible, and can be
simply astounding.

~~~
qhoxie
To me, your comment spells out quite conclusively that you have not been part
of a good pairing environment.

It is good that you see the knowledge transfer benefits, but I much prefer
thinking of it as knowledge _distribution_ rather than _transfer_. By this I
mean that your setup creates continual knowledge gaps and then fills them in
the pairing session. That seems much less valuable than actually distributing
the knowledge throughout the team by pairing all of the time.

I recommend you keep an open mind about the other major benefits of pairing
and that you actively seek good pairing opportunities. It is worth it and you
will know it when you experience good pairing.

~~~
skolor
It was a terrible pair programming environment. Pair programming was simply
being used to up the average grade of the class (which succeeded).

I disagree with saying that constantly distributing knowledge by always
pairing is a better situation. It makes the assumption that everything that
can be known about a system is already known, which doesn't often (ever?) hold
true. By separating out, you can cover far more area and find more of those
unknowns, while coming together for regular pair sessions helps spread that
newly discovered information around.

~~~
qhoxie
_It makes the assumption that everything that can be known about a system is
already known_

No, it does not. I'm not sure where you extracted that from in my comment.

Also, if you are aware that your environment was terrible, it seems
presumptuous to assess the benefits of pairing in a good environment. I assure
you there is more than teaching at play.

------
projectileboy
I used to be a big pair programming zealot, but I've backed off, since I've
seen it fail with so many people at so many places. Having said that, the
times I've worked in good pair programming environments have been the
happiest, most productive times of my life (at work, anyway).

So then, what constitutes "good"? This article seems to focus on the code,
which I think can matter, but I believe is much less important than the people
having the ability to pair effectively, which in my experience consists of two
things: (1) the ability to clearly articulate what one is thinking, in real-
time, and (2) the ability to allow your partner's ideas to be better than your
own. It also helps if you don't get annoyed by someone asking you questions
while you code, but that's less important, because you'll get over that if you
and your coding partner have (1) and (2).

~~~
askorkin
I agree with you, I suppose I tend to take those things for granted, possibly
because I've been fortunate enough lately to work in environments where both
1) and 2) are pretty much a given (lucky me).

Pair programming is an agile practice and in my experience it is a LOT easier
to do agile when you have good people on your team, not just good developers,
but good human beings.

------
lacker
I've had some good, some bad experiences with pair programming.

The best experiences were when both of us were learning a new API and type of
program. That's the sort of thing where you are likely to make lots of small
mistakes, and it's a lot less frustrating when you have someone else to help
catch them.

The worst experiences were when the programs were relatively easy, and there
was just a lot of stuff to be done. The person watching gets bored, and the
person coding gets distracted.

I feel like if one person is confident they can bang something out, just do
that. If it's the sort of annoying programming neither of you want to do, it
helps to pair. Hard to have general rules though for such a personality-
dependent activity.

