Ask HN: How useful is Pair Programming?

How useful and practical really is Pair Programming? Does it really work and scale up well?

What are the advantages and disadvantages? Statistical data/study would help.

The fact is that very few studies have actually been done so most of what you get are anecdotal accounts. I think pair programming has it's uses, for example, when a developer is stuck on a problem and can't move forward it's often helpful to have another set of eyeballs, but I have yet to see it effectively used full time (except for consultants who get to bill out at a double rate!).

A good book to check out with some counter arguments to pair programming and XP in general is "Extreme Programming Refactored: The Case Against XP".

From what I've seen, this is something with a lot of hype. I've seen a lot of smoke, but little fire.

Anecdotally, I've heard and seen that it helps, and that it hurts. I've seen people praise it as the answer to all productivity problems (along with TDD and ATDD, of course) and I've seen people curse it.

My opinion? It's good for leveling out the programmers on a team. If I had 6-8 team members I might have one pair going at all times -- usually the pairing up a weak/new developer with somebody who can help him. But I wouldn't expect productivity improvements -- I'd simply use it as a way of level-setting the team. It seems like a good mechanism for bringing people up to speed quickly.

Having said that, you have to let the team be the judge. If they like it, do more of it. If not, don't. Whatever you do, don't let hype and religion get in the way of the team performing. Life is too short to make it miserable by doing something everybody thinks is stupid.

Some of the TDD guys are doing ping-pong pair programming. That's where person A writes a test for new code, then person B writes code for the test and then writes a new test for new functionality. It bounces back to person A, who writes the new functionality and then a new test for new stuff, etc.

That at least seems more interesting for folks.

Personally, I don't like it. But I try to be open-minded about it (especially since I teach this stuff!)

Be aware that in some anal-retentive shops, pair programming is a security violation. (You're not supposed to be sharing your terminal session with anyone)

Pair-programming as a dogmatic part of the development process is, IMNSHO, very overrated.

Coding standards, simple interfaces, commit policies, etc are far more important.

Pair programming is useful for,

* Building small but critical pieces of code which everyone interfaces with on some level inside a group (a core plugin API would be a good example)

* Knowledge transfer. I use PP extensively to work-in new people and get them comfortable with a codebase, svn commit policy, documentation, etc. (I let them choose the tools, read on for more on that).

* Solving short coding problems in a common piece of code.

Code review also plays a much more important role than PP. The ability to read, understand and change each others code should just be built into the development process instead of trying to force an artificial level of quality/shared-knowledge via PP.

As an example, in my spare time I'm implementing a simple and clean Ruby version of some core functionality that we have in C# and JS (yes, I know, odd combination). A colleague is tracking my commits and implementing the same system in Python (also in his spare time). At any point in the future, someone wanting to implement this in Perl (for example) can just follow the commit changes on this reference implementation.

PP is also tricky when you choose to do something other than C# or Java, because in those cases you have a common IDE that's used in the company.

If you're doing anything unix-y some people will use emacs (setup their way) and others screen + vim (setup their way). Some poor misguided fools will use Notepad++ on Windows, and while that's fair enough if it works for them, that doesn't help matters any for PP.

I'm not dismissing PP, but the XP model just isn't suited for every environment.

I've read that pair programming is good for mediocre or novice programmers.