

Promiscuous Pairing: Do it often, do it fast and learn from it - stevejalim
http://blog.semantikoz.com/2012/03/25/promiscuous-pairing-do-it-often-do-it-fast-and-learn-from-it/

======
jrabone
What ... the ... f __*? Blindly pushing pair programming is bad enough, but
deliberately _trying_ to avoid 'flow' ? That's about the worst idea I've heard
from the cult of mediocrity that is 'Agile'.

Pairing on everything is a disruptive waste of both programmers time, unless
one programmer is hugely less experienced - in which case, it's not pair
programming, it's coaching, and coaching is a different skill set that you
can't expect everyone to either WANT to do or to be any good at.

Pairing on all design / analysis spikes is just about bearable, and maybe
there are benefits to having everyone switch around spikes quickly.

~~~
moss
Pairing with other experienced programmers works very well for me, and has
made me more effective as a programmer. I've also seen our junior developers
learn a lot from pairing with each other. In my working environment, with
other people who enjoy that style of work, we think it's pretty great.

It obviously doesn't work well for you, so I strongly recommend not doing it.

Why is it so terrible that people are playing with interesting, creative,
sometimes crazy new ideas, and sharing their results?

~~~
jrabone
I have had some good experiences with pairing where I've learned a lot, but
more often feel that I've gone for weeks without ever feeling the flow, the
point where all the pieces of system come together for me and I can see end-
to-end what needs to be written, where and how, and that's what I write code
for; if you took that away I'd give up tomorrow and become an accountant.

It's more the happy-clappy tone of these articles that grates than the fact
the someone's done it and written about it. As someone else pointed out, the
experiments are never controlled, never peer-reviewed, and often
unreproduceable, but they're always presented as the next great thing to hit
software development. It's time to stop with the bullshit, stop with the
certified courses, stop with the pretence that if only your team pushed bits
of paper around a whiteboard they'll magically become 10 times more
productive. Instead, find out how each individual can be the best developer
they can be, and facilitate THAT. Of course, that requires investing in actual
people management, which is something that is in short supply compared to
agile-methodologies-du-jour.

However, I've also seen situations where two junior devs have produced some
appalling edifice of code between them, so perhaps that's an argument for
rotating pairs faster. Personally I feel both they and the company would have
better off if they'd been coached by someone with more experience, but that's
not pairing, the power relationship isn't equal.

------
ArloBelshee
(I'm the author of the original paper. So take my ramblings here with a grain
of salt.)

The experimentation that led to Promiscuous Pairing was certainly based on the
practical. It was not scientific; it was process engineering. We had no goal
to make a great discovery. Rather, we had to ship software RTFN, so we were
optimizing our process to do so.

The company board had told us that they were liquidating the company if we
didn't have 2 signed letters of intent at the end of the trade show on May 25.
We started the project in October, using a traditional development approach
(what we'd been doing for the last 2 years).

On Jan 15 or so, I got the group together and asked. 100% of the engineers
agreed we had a <5% chance of even having a sales demo ready for the trade
show. We were guaranteed not to have enough to get a sale.

So we were desperate and had, literally, nothing to lose (and no time to lose
it in).

That was why we were so extreme. We measured the outputs that mattered to us
(defects, long refactorings, output), and we reviewed our process each
iteration. We did 1-week iterations (industry, as we learned later, was doing
3-4 weeks at the time). We continually developed qualitative heuristics and
used our quantitative numbers to filter them on viability. We needed to know
what would work faster than any quantitative approach could tell us.

And then we just tried all sorts of stuff. As we got more useful heuristics,
they encouraged us to try more bizarre stuff. One of those heuristics was that
learning was king: rate of progress == rate of invention == rate of learning
stuff (techniques, domain knowledge, ideas that others on the team had).

That was what led us to try the very short pair swap times.

In the end, we stayed with them only because they worked. And man did they
work.

5 years later, Ward & Jim convinced me to write up the experience for Agile
2005. Then a couple of other teams tried it.

Interestingly, many of them had exactly the same direct effects from the
practice as we did - and those direct effects led to project failure, rather
than success (Mitch's team & paper is a fine example).

On the basis of that, my current assumption is that you should only use PP if
you're good at removing roadblocks and are already pretty low friction. PP
makes all problems glaringly obvious all at once, and gives you the info &
learning to address them. But if you can't address them quickly enough (or if
there are too many friction points) it just destroys morale and productivity.

I now think of this as a 400-level practice.

First learn to pair (this takes time - it's a set of skills). Do stuff to
improve feedback. Shrink all your cycles (we were shipping software 2x per day
and hit 100% of our 1-week, 2-week, and 3-month commitments before we tried
PP). Once you have eliminated that friction (we did it by fiat, since we were
basically being laid off otherwise), then PP can be an awe-inspiring tool.

------
jdlshore
A quick correction: OP describes Arlo Belshee's paper as a "research paper,"
but it's more properly an experience report. Arlo was working in a
professional environment with a team of programmers. That team tried a variety
of techniques for improving their productivity, from "no pairing," to
"extremely rapid pair switching," and measured the results. I have no doubt
that they saw the results they claimed, and that promiscuous pairing worked
well for them _in actual practice_ in a real, professional programming
environment.

And... this is an experience report. Their "experiments" weren't controlled,
blinded, or anything like that. So there are almost certainly contextual
nuances that haven't been discovered yet. What worked for Arlo's team won't
necessarily work for your team.

And... this is true of nearly all software development techniques. There are
hardly any controlled, blinded studies of software development techniques that
are worth a damn. So if Arlo's technique seems intriguing, try it. Just don't
(a)hold it up as proven technique, because it's not, or (b)get angry that it's
not scientifically proven, because chances are very, very good that none of
the software development practices you love have been scientifically proven
either.

PS: An interesting followup experience report from a team at Microsoft that
tried promiscuous pairing for a while:
<http://dl.acm.org/citation.cfm?id=1155480>.

------
delinka
I could see this as an interesting exercise during certain kinds of workshops
or camps. Or during a week of low-stress, no-deadline work in the office. I
can, however, see The Suits latching onto this as The Next Big Thing. And it
will be about as useful in an every-day work environment as making your
programming staff take support calls during their coding time - context
switches cost _lots_ of time and reduce productivity.

~~~
moss
My understanding is that the Promiscuous Pairing idea was started by real
developers working on a real project with tight deadlines. The point of the
paper is that, counterintuitively, the approach worked very well _in
practice_. So I wouldn't be so quick to dismiss it based on first principles.

That said, it certainly depends a lot on context. My team at work has tried
full on switch-every-ninety-minutes Promiscuous Pairing a couple of times.
Once, it worked really well: everyone started knowing the code much better; we
got more done; we spent less time stuck and confused and more time producing
quality software. Another time, it was a nightmare: everyone felt rushed and
confused; it seemed like we were constantly being interrupted; we never felt
like we were getting anything done.

I'm not entirely sure what made the difference. Our going explanation is that,
the second time around, we had a higher baseline level of interruptions
already, so the constant switching just added stress and made it impossible to
focus. We haven't tried switching that aggressively since then (although we've
been considering it lately, as the circumstances seem better for it--that's
why it's on my mind right now). On the other hand, it's still rare for us to
switch less than once a day, and that's been absolutely great.

------
jonathanwallace
We have a variant of this for new hires that come onto our team at
<http://highgroove.com>. You'll pair with every existing highgroover over the
course of your first 5-6 weeks.

Also, this sounds very similar to the benefits I see when running code
retreats, <http://coderetreat.org/>. Though the problem domain doesn't change
throughout the day at a code retreat, its interesting to watch the diffusion
of ideas and knowledge.

------
moss
The article's link to the original paper doesn't seem to be working. Here it
is:
[http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pd...](http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pdf)

