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.
Curiously enough my personal best-ever development experience was with exactly the 90m regular pair switching talked about here where we paired the most/least experienced on particular stories.
It was brilliant. Great fun. Energising. Hugely productive. Especially when I was the most experienced person on the pair.
I don't understand Arlo Belshee's emphasis on the lack of flow in this setup in his original paper. Personally I've found the combination of good pairing + TDD to be a recipe for getting into flow very quickly. It seems designed to produce those little nuggets of problem/reward that suck you in and keep you grinding away.
The practice certainly hasn't worked for everybody (check out Mitch Lacey's try at using it for example http://www.mitchlacey.com/resources/adventures-in-promiscuou...) - but having tried it once I would be keen to try it again and try and figure out the contexts that are causing it to work/fail.
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?
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.
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.
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.
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.
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.
(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.
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.