Pair Programming Showdown

Some good comments so far. I've finally gotten around to posting my thoughts here: http://martyhaught.com/articles/2009/06/01/pair...

I haven't pair programmed a day in my life, but I imagine it makes it easier to stay on track and therefore be more productive. As a solo developer I often have only a few hours of serious coding in a day. The rest is usually filled with distractions (random mind block, email, twitter, etc.) all of which having a pair kind of eliminates.

Simple Wins:
* don't spend half a day(or a week) lost in the weeds on something a coworker could've helped you get bootstrapped on
* less of a bus factor on software as its developed, hopefully leading to easier maintenance
* talk about code as you're writing it instead of peer reviewing.
* having to continually talk about your software normally keeps you from wasting work hours browsing unrelated material

We currently do remote pairing on a two man team with mixed productivity. Mixed only because we're well aware when either of us are slacking.

Tough Spots:
* We shift our sleep cycles to get more overlapping time, I'm in Boulder, CO USA and he's in Christ Church, NZ. Still only gets us about 4-6 hours of overlap.

Winning Spots:
* using screen with shared input(screen -x) to write the code, apple screen sharing doesn't cut it.
* Being able to use the same editor and really let each other drive when we want to express ideas
* leaving screen open for hours on end

Hope the formatting didn't get ruined too bad.

positive:
* distractions are less common, it needs to be something that distracts both of you; get back into "the flow" faster (also a reason to do TDD); helps those among us with Attention Deficit be productive at *all* (this is an important one for me).
* higher bus number, more team ownership of code, less personal jurisdiction
* communication of design decisions is much easier/faster: "here, let me show you what I mean."
* creative tension, generally leads to better design decisions, better names for variables/classes/etc, better quality. Automatic "code review" on all pair produced code.
* because you've cut the number of concurrent tasks your team can work on in half, you've made it easier to coordinate a larger team and juggle the team's current tasks and priorities. In other words, pairing makes it easier to scale the team. Your team members are less likely to step on each other's feet.
* team culture grows more quickly, quick tips (did you know how to do X in vim? see how inject makes this simpler?) spread through the team more quickly. This could be mentoring of junior developers, or new fresh ideas for senior developers, or peers balancing and pulling each other out. A pairing team tends to gravitate towards the *highest* common denominator, versus individuals working together, tend to be bottlenecked by the weakest link.
* pairing and TDD(BDD) go great together, even if you aren't occasionally ping-pong pairing
* morale boost: team camaraderie grows faster.

Because of the above, pairing usually results in better code, done in less time, with more team members able to take ownership over it, than if the developers had worked on it individually.

difficult or negative:
* requires soft-skills, i.e. getting along with other devs, communicating, not being stubborn, etc.
* good pair programming is a learned skill, but often is treated like something that should Just Work (and is obviously no good if it goes poorly on the first try).
* the pairing experience can be spoiled by either person in the pair.
* programmers are overwhelmingly introverts, and we would much rather just work (and be) alone, even if it isn't the best thing for the team.
* fewer tasks can be done concurrently. When you are being asked to finish 20 "highest priority" tasks by yesterday, even though it is probably faster to have four people pair on them, doing only two tasks at a time, our instincts are to divide and conquer (four tasks concurrently).
* either there is no music (no headphones) or you need to agree/compromise on what to listen to.
* it can be hard to replace the personal pride of "I did this" with the team pride of "we did this", even if "We did this" really means "I did this and so-and-so helped out and it was better than if I did it alone."
* pairing (done right) can be more exhausting than working alone. this is mostly because you aren't getting distracted as much, you are forced to defend your (often bad) ideas, and you have gotten more done. but still, it's more *work* than working alone.
* working with different editors is tricky. doable, but tricky. it slows you down and dampens some of the benefits.
* remote pairing is tricky. doable, but tricky. it slows you down and dampens some of the benefits.
* mindless routine tasks feel like a waste of time, and sometimes they are.
* research and spiking and experimentation are sometimes very appropriate for pairing, sometimes not at all, and it's hard to tell when is which (very context sensitive).
* pairing without the cadence of TDD(BDD) often feels awkward. (ahem... perhaps you should start to TATFT then!)
* pairing done wrong (and sometimes even "done right"), might not *feel* very productive to one member of the pair. at that point, that person probably feels it is a waste of time, and the other person feels slightly guilty for wanting to pair. Note, this might be far more about emotions and perception than about logic and empirical reality.

The above negatives mean that (in my experience), even when an entire team agrees that pairing is a good thing (in the abstract) and the team has agreed to pair some or most of the time, the team often pairs less often or gets less out of it than expected.

See also these posts: http://www.jroller.com/obie/entry/pair_programm... http://anarchycreek.com/2009/05/26/how-tdd-and-...

I can't believe you came in and Steve Yegge'd my blog. This is a really good reply!

The best way I can put it is this: ever ask someone for help with the crossword puzzle? How quickly do you think you and a colleague could finish the crossword? I'd bet you'd solve it faster than if either of you worked it alone. Two heads are better than one. Of course, you don't need two heads to cook up "Hello, World" but you'd be surprised how much you can learn from other developers simply because they approach the problem differently. It's the ultimate cultural exchange program for developers. The only concrete advice I can offer for execution is: make sure you share the keyboard. There's a huge difference between pair programming and one developer watching the other write code.

Speaking as a college student, I find it very useful to pair program.

I started doing it this semester with a project I had with a collegue and it definitely has its benifits. For us, one of the obvious benifits was a speedier dev cycle, since our commulative knowledge aloud us to plod along much more steadily.

Another one that was especially important for us was that, at any point, either of us was capable of coding any of the modules of the app. This redundancy is also great in teams since a missing member doesn't have that big a consequence.

Thumbs up from me.

What's the best way for the senior developers on a team to approach junior developers and suggest they occasionally pair? I've seen lots of organizations where I think the full-time senior devs don't spend enough quality time mentoring the junior devs. Does pairing need to be mandated from management?

Lead by example. Pairing isn't only good for "junior" devs. Pairing is a fundamentally better way to tackle problems, and I can't think of a better way to convince anyone that pairing is useless than to have management mandate it.