Rethinking pair programming

I originally argued that artisan software was desirable because it made more inspiring software, and because it made programmers less miserable. But the world changed recently, and for a while I think we’re going to need artisanal software simply to get software built at all.

While we’re on the subject of the economy, though, I wonder whether pair programming is a great idea. It’s better than huge distributed teams, and it avoids the mythical man-month problem by not generating endless, enervating meetings. But, compared to solo programming, it doubles labor costs. When is the benefit justified? (My guess is that, in the optimal case, pair programming is best for training, for maintaining dying code, and when fixing bugs will be exceptionally difficult or costly. But I used to detest having a lab partner, so perhaps those memories unduly influence me. Hard data and sabremetrics should yield real results on the question, eventually.)

---

Update: This post generated more reaction than the Tarte Tatin. Which is saying a lot. But (unlike that tasty apple confection) this one was half-baked and off-center. The change, I think, is that a few months ago our development baseline was “best practices”; now, it’s “everything is on hold or cancelled”.