From the moment I heard about pair programming a little more than 2 years ago, I knew it was a fantastic idea.  It immediately clicked for me - put two people to do one job and chances are, assuming the two people get along, they would do a better job and finish faster than one person alone.  But of course, not having done it in practice myself, I read a lot of skepticism on pair programming.  I was starting to doubt whether or not it could be an effective means of software development.

I'm putting the controversy to rest.  After having pair programmed for about a year, there is simply no doubt in my mind that pair programming is a far more efficient means of software development.  In my experience, pair programming has had the following benefits:

• Faster design of both simple and more complicated solutions - Ideas for solutions flow freely between me and my pairing partner and as the ideas come out, the other person runs with it faster than the creator of the idea.  A solution that might have taken me hours to think through often develops in a matter of minutes.
• Far more robust and less error prone solutions - Since all design ideas and implementation is developed and coded by two people, each with their own perspective on the idea, flaws are identified quickly and a solution to the flaw is almost always blurted out immediately.  This results in more solid design, followed by more solid code (since one person codes and one person watches for coding mistakes) - which in my experience has reduced defects in the solutions we develop by more than 80% when compared to solutions I used to develop by myself.
• Less spaghetti code - I know you've been here: You find a flaw in your design or code and immediately you think of a quick-and-dirty work-around...you convince yourself to implement the quick-and-dirty work-around right away just so the error will go away for now, and then you'll return to this piece of code later and fix it right - and of course, it never happens.  You never return!  The result?  Spaghetti code that even you don't fully understand. Well, even though my pairing partner and I both admit to writing such spaghetti code on our own, we never do it during a pairing session.  The conversation is almost always the same and it goes something like this:  “we could fix it by doing XYZ, but that's probably not the best solution“ says the first person, to which the second person replies “lets just do it right so we don't have to pay for it later“ and the discussion is over.
• Reduced need for documentation - Since any given portion of a pair designed and developed system is understood by at least two people, the need to document is less important for simple and rudimentary portions of the system.  Documentation is still needed for complex designs - but when pairing, even that type of documentation is easier to write because you can quickly identify the important aspects that should be documented – rather than documenting everything for the sake of documentation.
• Reduced need for unit testing - This benefit might surprise you.  After all, most of the pairing advocates out there (such as Kent Beck) and the “Xtreme Programming“ methodology call for “test-first programming“.  I don't agree that test-first programming is always the way to go.  It largely depends on what you are developing.  If I'm working on code for the Mars rover project, yeh, test-first programming is the way to go.  But for the vast majority of projects, IF YOU ARE PAIR DEVELOPING, in my opinion, you don't need to spend as much time unit testing.  By pair programming, I have been able to reduce more than 80% of the defects “our“ solutions, we create better designs, more robust code and create a better all-around system.  That last 20% of defects (of which, only 5-10% would get fixed by test-first programming anyway) is not worth the extensive amount of time it would take to write all the unit-tests first.  In fact, by doing test-first programming, much of the gains of pair-programming is lost and the overall development time might be increased.  So my advice is this:  If you did test-driven programming before you started pairing, then continue with test-driven programming even after you pair.  However, if you never did test-driven programming before, you have even less reason to start after you pair.

I should say that it goes without saying that in order for pairing to work, it takes the right pairing partner.  But the good news is that there are plenty of fish in the sea.