I think pairing sucks. Based on my personal experience with it. I'm just not cut out for it, mostly. I'm more comfortable and productive in the the "private office with a door" environment that DeMarco and Spolsky advocate. I don't dispute that pairing works for some people, in some situations.

Despite the overall "we're so smart and so much better than everyone else" attitude in this piece, the still-relevant conclusion is that pairing is not easy, requires large investments in both physical assets and people who want to work that way. He even admits that once your team is larger than a dozen or so, the feasibility of pairing starts to break down because of personality conflicts.

You've apparently been thrown off course by the love-it-or-loathe it reaction to pairing, but you're actually agreeing with the article. He's listing why it isn't feasible for most situations. (Though most people seem to interpret this as reverse psychology, though I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate).

But really I could write a long (sometimes contradictory) list of things that would help people program better that would get similar levels of reaction:

  * use vi
  * use emacs
  * use an IDE
  * TDD
  * unit testing
  * any kind of testing
  * writing documentation
  * using the highest level language possible
  * using C++
  * using anything but C++
  * source control
  * distributed source control
  * avoiding gotos

Judging by the slightly over-emotional responses in this thread to pairing you only need to find one good bit of software written without these tools/ideas and you can ignore them totally. Apparently, in your case, an individual not liking something, or it being hard, or requiring investment or not being suitable for all sizes of teams rules it out, which covers most of this list.

I would suggest doing hard things you don't like, which require investment and need to be applied appropriately to your context is a pretty good definition of "profesionalism", something sorely lacking in most software development shops but on the other hand just because it fits that definition doesn't mean it's the right thing to do.

I think that pairing, like many things in this list, can be appropriate and useful but I'm not about to burn anyone as a witch if they don't like it or practice it.

Oh your reply just crystalized one of the main problems I had with pairing. See, I use emacs and a bunch of command line tools. Almost everyone else in the shop used visual studio. I think one other guy used some editor he liked. So to pair with someone I had to use visual studio, which is like asking a master carpenter to use a hammer and saw that were picked up at Wal-Mart instead of the tools he had spent a decade mastering.

So in order to pair effectively, everyone has to use the same tools. And that's going to be a big problem for people who don't like those tools. I don't think the article really hit that point.

EDIT: Oh and your little aside: I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate is fabulous. Love it.