Completely agree on some of the points you raised, and that devil’s advocate is usually permanently resident on my shoulders, so I know where you are coming from.

1.) With regards to productivity, as I mentioned, Pair programming is not for everyone. There are people I know on my team (me included), who are far more productive when they pair than when they are not. This is not due to the fact that they can’t work independently, oh heaven’s no. Its mostly because of lack of focus. Its easier to get in a 2-3 hour slot of pure productivity as compared to sometimes getting distracted when working independently. Would I recommend pairing all the time ? Hell no. I find that if I pair maybe 2 – 3 hours a day, and then work on my own the rest of the time, I get the most work done.

As for TDD, I will be the first one to say that doing TDD will not keep your bugs away. Because there is no way to cover or even remember what cases are possible. TDD just gives me confidence that when I finally hit play, it won’t blow up for the silliest things like forgetting an operation or method call. When I write things with conditionals or tricky operations, TDD is my safety net to fall back on. Trivial stuff, I usually don’t bother.

2.) Well, even ignoring the fact that they might not have lengthy code reviews, I still find the fact that not having what you call generalizing specialists and common codebase ownership can be extremely fatal when that specialist goes on leave (happening right now with me, in fact…). I have had times when I worked solely on a part, and then when I went on vacation, things blew up and people had to spend a day trying to patch a trivial issue. And its not the fact that few programmers would time-bomb themselves with poor code, its the fact that they don’t know any better, not having been told there’s a better way (I was guilty of this when I initially joined). This is especially true if you hire a lot of new grads.

3.) I love vi-slingers. I love vi, in fact. And if someone tells me to pair all the time, I would be the first one to tell them to take a hike. Fact of the matter is, there are times when we need to sling some code on our own, and pairing or teaching someone else would just be a hindrance. In those cases, sling away. Don’t let anyone tell you otherwise. But just don’t frown upon pairing completely, because its often a useful and underused technique, and best of all, can help get you someone else who can maintain what you just wrote .

Finally, I moved blogs, so find all my new posts from now at http://theshyam.com
Thanks for commenting.

Yet… To be comprehensive, I think it’s nice to point a couple of things about pair programming and TDD:

1) Most technical managers readily believe pair programming increases quality. What they wonder about is productivity.

Not all companies have a quality problem with their code. Paradoxically, I work in a company where the work process generates endless piles of bugs – yet the company is a market leader: they have tester teams, their customers have testers teams, and although programmers like me tend to get very unhappy about the situation, there is not actually a business problem.

On a completely different line, I write and promote software in my own time. This is a do or die activity. I get strict when it comes to keeping code modular, but I don’t do TDD (and can’t afford pairing). Modular warrants that, when the s…t hits the fan, it’s actually hitting one out of many many tiny fans. TDD I use not, because the essence of quality (from a user’s perspective) is what the software does, and how many bugs software can tolerate before quality is actually affected.

If I build a rocket someday, I wll use TDD and cleanroom software. No bugs is great! Point taken.

2) If a company doesn’t use pair programming, they may not have time-consuming code reviews either.

I totally join in when it comes to avoiding distractions. Active pairs (programming or not) are much harder to distract than isolated workers. Distractions are a huge productivity sink at work – there’s been a good study showing that it takes 15 minutes to get fully concentrated after an interruption, aggravated by the fact that workers on an open floor office get distracted about every 15 minutes(!). Maybe that stands as one of the greatest, unproven arguments suggesting that pairs program ‘at least twice as fast as individuals do’.

Yet it may not be fair to oppose pair programming to long code reviews – not having pair programming doesn’t imply having lengthy code reviews, and having neither is not wrong in all respects… Single programmers own their mistakes fully, and as far as I know, companies that dedicate an extensive amount of time to code reviews probably overlook the fact that few programmers would time-bomb themselves with poor code.

Generalising specialists are created by rotating developers and common codebase ownership. Having a specialist handy may teach you less about a special problem than solving it yourself.

3) Last, but not least… It would be great if people acknowledged more often the social bias involved in pair programming – never mind open floor offices.

I seem to remember a lost era when the image of ‘bedroom geniuses’ coding smart stuff in their own corner was not unrespectable in the programming community.

One thing I love about new methodologies and processes is that they potentially open doors to different kinds of people. One thing I’d hate is seeing lonesome vi-slingers mobbed amidst a gregarious ’simple and social is code’ epiphany,

Don’t get me wrong. I love this stuff – a devil’s advocate is whispering in my ears.

Cheers