Pragmatic Pair Programming

Pair programming. It's nasty. It's evil. The only people who actually do it are those Extreme Programming zealots, and we all know what they're like. Pair programming deserves to be condemned to the trash heap of practices that failed, destined to go down in history as the black sheep of agility. Right? Well, maybe not. Maybe pair programming does have some value after all. Maybe it can be redeemed if done the right way, the pragmatic way.

Pair programming. It's nasty. It's evil. The only people who actually do it are those Extreme Programming zealots, and we all know what they're like. Pair programming deserves to be condemned to the trash heap of practices that failed, destined to go down in history as the black sheep of agility. Right? Well, maybe not. Maybe pair programming does have some value after all. Maybe it can be redeemed if done the right way, the pragmatic way.

Let's re-examine pair programming in a spirit of discovery. Let's learn how to avoid the many pitfalls inherent in it, and carefully refactor it to yield tangible, measurable benefits. Let's make sure we're not doing pair programming for its own sake, but only because it makes us more productive, increases code quality, and boosts team cohesion.

About Matthew Bass

Matthew Bass is an independent software developer, entrepreneur, speaker, and writer. He has over ten years of experience across a diverse set of technologies and has worked at places like SAS Institute, the world's largest privately held software company. An agilist from the very beginning, he continues evangelizing and experimenting with pair programming, test-first and behavior-driven development, and continuous integration. Matthew has spoken at several regional and national software conferences and regularly writes for publications like InfoQ.

More About Matthew »