Why you should pair program

My new job uses pretty strict XP for software development. I say pretty strict, because as I understand it, they started with strict XP and have adapted it to their needs. To me, coming from a half-hearted Agile/Scrum shop, the two most noticeable features about XP are pair programming and Test Driven Design|Development (TDD).

It seems like, to most people, pair programming is the biggest mystery of the whole process. Before trying it full time, even I was a little bit skeptical as to whether or not it was really worth it. I mean, really, two people doing one job?! ;) (A little background for you non-technical types - pair programming, in a nutshell, is two people sitting at a single computer working on something collaboratively.)

The biggest and most obvious question about pair programming is how can you possibly get as much work done when working in pairs. It's usually phrased something like this:

- Jack can get feature x done in 9 hours.
- Sally can get feature y done in 5 hours.
- Can Jack and Sally get both features done in less than 14 hours by pair programming?

Only having pair programmed for about a week (8 days to be precise), I don't know that I have a good answer for that question quite yet. I also think that the question is going about it the wrong way.

For starters, here's what I have noticed about pair programming so far:

- Having begun a new project on a new framework on a new platform, I came up to speed at least 3-4 times faster than I would have on my own
- Knowledge transfer happens in real time and is unavoidable
- Code reviews are mostly unnecessary
- There are far fewer bugs
- When one of us gets stumped, about 70% of the time the other person has an immediate answer to keep the pair going
- Time wasted trying to run and debug code because of typos, etc. is nearly eliminated
- Time wasted on Digg and Reddit drops to 0
- The job is much more engaging so I don't mind a Digg-less lifestyle
- I make fewer design decisions that I end up having to change later
- My brain hurts when I go home every night, but in a good way

Here are some other reasons why I think the question asking about the 14 hours is overly simplistic:

- The cost of bugs, even ones caught internally, is HUGE
- Code that can be read by 2 people is much more likely to be able to be read by more than 2 people
- Code that can be read by more than 2 people is much easier to maintain
- When a pair says something is done, it's more likely to actually be done, so tracking progress is easier

I think a better way to phrase the 14 hours question is this: Is a team's velocity higher when pair programming? Keep in mind that bugs don't count toward velocity, only new delivered features do.

Even with all these bullet points above, I would guess that pairing is still around 50% faster than doing something on your own. Think about when you're writing code, are you really limited by your typing speed? Most of your actual time is spent thinking about the problem, trying to find the right approach, googling, and testing. Having a pair to work with seriously cuts down on the time required for these parts of development.

So ask yourself, should you be pair programming?