One Hour of Pair Programming


I am taking a two day course this week on Unit Testing, Test Driven Development, and Refactoring put on by Net Objectives.   Our instructor, Rob Myers, has a fair amount of experience working as an Extreme Programming coach.  In an interesting twist to the usual classroom experience, the first thing that he had us do was pair up with another person in the class.  After a few minutes of mingling to find a partner who either had complementary knowledge or was someone that you hadn’t worked with before, we moved around so that the newly paired classmates were seated next to each other. 

 

Since I’ve never pair programmed before, I was anxious to give it a try.  But we had to wait almost the whole day to do a programming assignment.  Finally, in mid afternoon, we came to an exercise that we got to do together.  It was a very simple example which we were to tackle using a Test First approach with NUnit as the test framework.

 

So it’s pretty tough to gauge a practice after an hour, but my first impression of pair programming was positive.  It was fun to work out a simple approach, work through some issues that came up, and ultimately get to see the NUnit green bar for the successful exeuction of the tests for the code that we wrote.  My partner did much of the driving and I learned some shortcuts in Visual Studio.  We each brought up different ideas when stopped by a problem, and we caught each other’s mistakes before the compiler in many situations.

 

All in all, the hour flew by.  I think it would be interesting to try this for a longer time period to see if we really could be more productive programming in pairs. 


Comments (4)

  1. Eric K. says:

    Personally, I prefer pair programming in nearly any situation.

    Whereas a single programmer may think he’s ‘in the zone’ and knocking out code as fast as humanly possible, the simple fact is that "two heads are better than one".

    The code that either single programmer knocks out on his own may actually be inferior to that which the two programmers discuss and agree on. When you have two people with complementary knowledge, additional options arise from comparing and contrasting their approaches and more options arise.

    Management loves to divide up a programming department into separate tasks assigned to single programmers. I think this is a huge mistake.

    Pair programming can accomplish programming and design tasks faster and with higher quality than isolated programming.

    Go ahead and assign two projects to two programmers. But let them–encourage them to team up on it. You’ll get two projects done faster and better than if they were done independently. And both programmers will have intimate knowledge of the functionality built into both projects.

    So…. what ws the advantage to islated programming again? As far as I can tell, it’s simply that of unconfused management.

  2. John says:

    Even though I’ve never done pair programming "for real", I’ve definitely ending up doing it without knowing it. Sitting over the shoulder of a fellow programmer who was banging his head against a problem for a few hours and helping out.

    I do wonder if the amount of good code that can be written by a pair would equate to the amount of good code written by two programmers alone. Has anybody actually done any studies on it?

    The other thing that I would worry about a little would be how to pair the people… would it be a good idea to pair a very strong programmer with a weak programmer, etc.

  3. Rob Myers says:

    Most of the studies I’m aware of were done by Laurie Williams at North Carolina State University.
    <br>
    <br>I recall that one study indicated that pair-programming was about 15% more efficient than working individually on the same set of tasks. That’s not 15% more efficient than one head. That’s 15% more efficient than the same two people working separately.
    <br>
    <br>There are so many advantages to pair-programming that aren’t immediately obvious to developers or to management. As a coach, I’m a big fan of these whole-team effects:
    <br>
    <br>Self-management: Who is going to surf the net or spend hours replying to every e-mail message while pair-programming? No one.
    <br>
    <br>Fewer interruptions: Are you less likely to interrupt two people who are obviously working together to complete a task?
    <br>
    <br>Less code-attachment: I discovered that individuals have less of an emotional attachment to &quot;their&quot; code if they wrote it in pairs. They still care about the quality, but they’re less afraid to have a third set of eyes looking at it, or another teammate changing it. In effect, pair-programming facilitates collective code ownership, another useful team practice.
    <br>
    <br>Those are some of the less obvious benefits. Of course, you get some code-review, some cross-training, and someone to keep you from running down a mental rat-hole while you’re writing code. All great benefits. But I think that the less-obvious whole-team effects are equally interesting.
    <br>
    <br>Rob Myers
    <br>
    <br>PS: It is true that you had to wait most of a day to code. Ye gads. We’re considering a fix for that. So much cool stuff, so little time…

  4. Rob Myers says:

    PPS: I wanted to comment also on the pairing of &quot;strong&quot; and &quot;weak&quot; programmers.
    <br>
    <br>Again, there are the obvious arguments: You get cross-training, and your project risk drops. Also, the stories abound about how &quot;senior&quot; developers usually learn something new and interesting from the &quot;junior&quot; programmers.
    <br>
    <br>But I ask this one simple question: Without pairing, what are your so-called &quot;weak&quot; programmers working on now?!
    <br>
    <br>If, like many software teams, you have one Paragon of Programming who is designing/coding your high-quality mission-critical code, and a bunch of newbies building extraneous side-features using the Copy-Paste Pattern and Sleep-Deprivation Design, what will your product look like?
    <br>
    <br>Professional programmers know how to work in teams. Their experience is more valuable when they act as peers and mentors, not as competitors, within the team.
    <br>
    <br>Rob Myers