Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Pair Programming

I’ve spent a few hours over the last two days pair programming with Adrian. We’re working on a pretty huge project at the moment, and we’ve just started work on the coding phase, overlapping the design phase. I had tried pair programming a few times before with some success, but this time in particular the benefits of the approach were crystal clear. In total, we’ve defined 4 database tables, a number of functions and a simple class. Working separately we would almost certainly have created more lines of code. However...

  • The code we have produced is free of bugs. That’s a pretty bold claim to make, but every line has been extensively discussed, tested and looked over by two pairs of eyes.
  • The naming conventions for both the Python code and the SQL are consistent and well thought out. We’re both happy with them, we both understand why the names have been chosen and we both know the naming style well enough to continue it throughout the project.
  • The coding style itself is ultra-clean and approved by both of us. We have a preference now for everything from quoting styles to whether or not a docstring should finish in a full-stop (it shouldn’t). We also know enough to keep these standards going for the rest of the project.
  • We learnt stuff from each other. KDE shortcuts, new features in Python 2.3, neat ways of laying out SQL statements, Python functional programming idioms.
  • We started coding, or at least started discussing the code, at the time we had scheduled for the start. There was no procrastination.
  • At no point did either of us check our email or check any blogs. productivity++!
  • We both know the code that we have written inside out and back to front.

Altogether they have been highly productive and successful sessions. Our plan now is to pair program the system core, then work separately on the additional modules that don’t have major dependencies on each other. There are only two of us developers working on the project so pair programming the whole thing isn’t really practical, but the benefits of working together the core modules are obvious.

One last thing: it was a lot of fun!

Posted 23rd October 2003 at 4:11 am

This is Pair Programming by Simon Willison, posted on 23rd October 2003.

View blog reactions

Next: Progressive page updates

Previous: Knoppix

13 comments

  1. Thanks for writing about your experiences, Simon. What you've mentioned here just might be enough to convince my coworkers (and management) to try pair programming.

    Sam Buchanan - 23rd October 2003 16:41 - #

  2. Oh, Pair Programming rules ... the problem is convincing *management* that it's a good idea.

    Also, I wonder how sustainable it is. Maybe you'll get tired of it and want some "space" after a while.

    Joe Grossberg - 23rd October 2003 17:29 - #

  3. On sustainability, I should think that some careful decisions are needed about *which* bits to pair program. As Simon touches on in his post, core functionality is a good choice because then you both have a deep understanding of the core, as well as certainty that pretty much all of it is debugged. Leaving you to extend on your own whilst keeping with the ethos of the design as a whole.

    Meriq - 23rd October 2003 20:11 - #

  4. I've recently done a bit of pairing on a project at work, and my experience closely mirrors Simon's.

    It helps that my partner and I are good friends, as I'm sure Adrian and Simon are. There are certainly people more and less open to the idea of working closely with someone. I'd say that pairing can have such a profound effect on teamwork and productivity that the process overhead needed to support non-pairers might not be cost-effective.

    That's a bold claim, too. ;)

    I am curious, though, why you (Simon) say that pairing the whole thing doesn't make sense. That is, if these benefits are clear, and go far beyond raw feature-production into teamwork and internal quality, what is the compelling reason -not- to pair?

    I've gotten some pushback on pairing from my CIO. He says his main concern is justifying it to his boss (CFO). There's a good bit of research done on pairing, and if you've got an open mind, I think it's pretty convincing. Of course, it took an act of congress to get a small cube partition removed, and pairing would have been near impossible in the layout originally available.

    Jeremy Dunck - 24th October 2003 05:38 - #

  5. I am curious, though, why you (Simon) say that pairing the whole thing doesn't make sense. That is, if these benefits are clear, and go far beyond raw feature-production into teamwork and internal quality, what is the compelling reason -not- to pair?

    Our development team consists of two people. The system we are working on (a content management system) is huge, and we're running it to some pretty tight deadlines. Since there are only two of us we really need to work in parallel once we've got the essential core pieces built.

    Simon Willison - 24th October 2003 06:30 - #

  6. Simon: It sounds just like my work experience (which I am currently doing). I'm learning loads about MySQL queries (like you can do querys on two tables all from one query eg. 'select a.id, b.username from a.table, b.tabletwo'), Red Hat Linux (terminal, ssh, suroot, chmod, perl, php, apache, python, bash) and PHP classes. I have even found time to explain to the designers about web standards, CSS and XSL(T). It's really helped to have knowledgeable people next to me as I was doing all this, asking me why I was doing things the way I was and giving me hints and tips to improve my code.

    zlog - 24th October 2003 10:59 - #

  7. Beyond the friendship necessary to pair 2 coders, do you think the pair must be of more or less equivalent skills ?

    P01 - 24th October 2003 13:01 - #

  8. First, I don't think friendship is a requirement. Respect is.

    Second, I don't think that having the same skill level is at all necessary. Various pair configurations have different strengths and outcomes. I think Pair Programming Illuminated is a great read, if you're interested in the topic.

    Jeremy Dunck - 24th October 2003 16:03 - #

  9. I asked about the skills 'coz in my ex-company there was a gap of skills between the rookie and senior developers. Due to some tight deadlines, the 2 rookies pair programmed the core classes of our biggest project ( a CMS ) while the 2 seniors were still busy with another project. Unfortunately the rookies were discovering OOP. They made almost no use of member variables, and had no grasp of the concept of reference. Damn! I think that was a big management mistake 'coz the tight deadlines never let us fix some errors of conception and implementation. Ok, the rookies produced some better code than what they would have done alone, but obviously they were not ready for that kind of project. And due to the deadlines and lack of experience of the rookies, I think pairing a rookie with a senior wouldn't have been productive enough.

    P01 - 25th October 2003 19:23 - #

  10. Nice to see everyones views on pair-programming. I've only just started learning about XP and only heard about pair programming, in one of my lectures, a few weeks ago. I assumed the process of pair-programming was a very rigid concept with rules just like other Software engineering techniques. I am hearing conflicting view in this page. Is that to say that there is no standard definition of pair-programming unlike other SWE standards? And another question to answer. What would you say the worst things about pair-programming are? Sustainability seems to be the only half decent disadvantage.

    Philip Nicholls - 14th March 2004 23:56 - #

  11. Philip,

    Pair programming is simply two people working on one piece of code, at one computer, at the same time. That's a pretty broad definition, and therefore there are many ways and techniques to doing it. Books have been written about it.

    I'd like to know what SWE techniques you know that follow a rigid set of rules and are also successful? Since you admit being new to XP, I hope you don't take offense at my assumption that you may be inexperienced in SWE in general...

    For a very negative view of XP, HackNot provides pretty lucid writing.. Not that I agree with much of it. Here's an article on the author's (newbie) experience with pair programming.

    If you're of the XP-bashing bent, there's one illustrating XP-as-cult which is entertaining reading.

    If you want a pro-XP review of pair-programming, I suggest reading ObjectMentor's Bowling score narrative.

    Read critically, and remember that both authors are selling their own version of the truth.

    Hope it helps...

    Jeremy Dunck - 23rd March 2004 22:29 - #

  12. Its for gays

    Dinesh Khetarpal - 8th October 2005 19:44 - #

  13. How the hell you can sit with disgusting colleague of your at six inches proximity unless you are gay. On the assumption 95% of the programmers are men. In no other profession in the world you have to do this to make living.

    Dinesh - 8th October 2005 19:47 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2003/10/23/pairProgramming

A django site