Archives

Tags

Showing articles written in August 2009. Show all articles

Arguments for pair programming

A while ago I found myself in the position where I needed to convince my managers that Pair Programming was a worthwhile business investment. I was recommending the traditional approach, consisting of a "driver" and an "observer", who optionally switch roles at semi-constant intervals.

I was conscious enough to know that getting the actual benefits across clearly was important as the whole concept could easily be misconstrued to mean something along the lines of: "Hey! I want to sporadically wrap all of the production staff into neat little bundles of two".

Below are my no-bullshit reasons why, from my own experience, pair programming/designing/writing works well. Now, I should mention that your own mileage may vary. I've had occasions where peoples ego's (perhaps including my own) have got in the way -- but that's a whole different issue! Anyway:

  • When working in two, people spend less time looking at forums, news and otherwise useless crap.
  • Increases the Bus-Factor. That is, the number of people that need to be hit by buses before a substantial amount of domain knowledge is forever lost.
  • If stuck on a problem, sometimes the best way to solve it is simply to ask someone to listen to you explain it (the answer becomes clear when you dictate the issue). This is a well-known phenomenon.
  • When seeing each other work, staff can really gain an insight into how they spend their days and why they are an important asset.
  • Staff can expand their skillset by observing each others experience and knowhow.
  • Two minds are better than one when it comes to complex problem-solving.
  • Bonding is always a plus.

Perhaps this list will help another cronie in convincing their managers of "pairings" effectiveness? Good luck.