Pair Programming: An Interesting Model

Image by lumaxart via Flickr

I read an article by the NY Times Online this past weekend and it really resonated with me. It's all about "pair programming" where two software developers work side-by-side, one as the "driver" and the other as the "navigator". Here's how the author defined it:

One person does the actual writing, or coding, and the other person checks it, corrects it and offers suggestions as it's being written. Programmers, or software developers, refer to these roles as driver and navigator.

At first, as the author points out, it would seem that this is two people doing the job of one person - and thereby an inefficient use of human resources. But as it turns out the end product is of such a higher quality that less resources are spent later in fixing bugs and such.

And it got me thinking that there are a lot of disciplines within business that could benefit from this concept. Quite often we work on our own to "develop" business plans, sales strategies, marketing objectives, or product roadmaps.  So, pair programming is just the implementation of the collective intelligence (a.k.a., "two heads are better than one") making these end products better.

But this shouldn't be taken to the extreme, otherwise you end up with "death by committee".  That would be taking collaboration too far because too many voices restrict the flow of innovation unless strict discipline is enforced. I think creative juices flow better when there are just a few people involved at a time and they recognize that it's an evolving discourse; you don't need to have all the answers going into it.

You also don't look so foolish when you're thinking out loud if there's someone else in the room with you.  :-p

Related articles by Zemanta

• Preoccupations: For Writing Software, a Buddy System (nytimes.com)