Share via

Trying out pair programming

  • Article

Greetings all –

 

My team has been reporting success with pair programming, so I wanted to try it out myself.  This week one of my reports and I paired up to do a bit of maintenance work where we’re moving some automated tests around and setting aside some to act as compatibility tests.  So it wasn’t exactly pair “programming” in the strictest sense but it was still pairing on nontrivial technical work and so essentially the same.

 

We had two pairing sessions this week, and then we’ll have another today to hopefully wrap the work item up.

 

I’m happy to report that it has gone well, much better than I expected.  My experiences matched those which my team and others in the industry have reported:

  • Many errors get caught immediately by the “navigator” (the person not typing at the time)
  • Work gets done in less elapsed time (clock time), although it may take longer in terms of “person hours” (clock time multiplied by # of people)
  • It’s more fun
  • It’s VERY mentally draining – I found that after 3 hours my productivity & focus started to decline
  • Having another person there helps motivate you to get through mundane work, and also pushes you to the highest possible quality standards

 

After having done pairing on this task, I now find it frightening to imagine any critical coding task being done alone by somebody.

 

I still haven’t figured out a clean way to schedule pairing (in the sense of accounting for it in the sprint backlog).  We are finding that velocity is a superior way to predictably schedule sprint capacity (as opposed to top-down scheduling by “person days”), which frees you from trying to do wacky mathematical translations from individual person day costings into pair costings.  But I still to wrap my head around the best way to explain the cost impact to management types.

 

My advice: try out pair programming – it really is a great practice.  I feel about pair programming the same way I did after doing TDD the first time: for tasks where it makes sense, I wouldn’t want to go back to doing it “the old way”.

 

Over & out!

Chris

Comments

  • Anonymous
    December 30, 2005
    Over the past couple of months we've been programming in pairs also and find the results suprising. We're doing it out of necessity more than design; we hired a capable yet inexperienced programmer to work on an online tax preperation site. Here's what we see...

    you're right, the navigator catches many errors before we compile. it seems to work best if the navigator is the more experienced programmer. resist the old "just let me drive".

    the learning curve is significantly reduced and the pair is forced to have the same understanding of the app

    about every 2-4 hours we take a break from pair programming and conquer the mundane stuff

    the productivity has increased some, but combine it with the increase in quality and reduced rework and the value of pair programming is seen. it's taken us about 2 months to see this payoff.


    *we've tried TDD in several places and didnt get positive results (maybe our apps aren't suited for it) but pair programming seems to the right idea in 70-80% of our development, research, maintenance.
  • Anonymous
    January 16, 2006
    true even i have experienced this but didn't knew this was a formal technique. the best part is you seem to think through all the scenarios. there is lot less code churn.
  • Anonymous
    March 01, 2006
    We have practiced pair programming and TDD successfully using the Microsoft .NET toolset for a few years now.  

    Check out this presentation from last month, it has some pictures and our experiences/best practices:
    http://www.thycotic.com/presentations.html
    (Look for Pair Programming)
  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=chris-flaat-s-weblog-trying-out-pair-programming