Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Having problems with Paired Programming

Expand Messages
  • Jim Little
    Kay already submitted several good answers, but here s some more: From: C & C Helck ... person ... me. In my experience, pairing
    Message 1 of 4 , Sep 16, 2000
      Kay already submitted several good answers, but here's some more:

      From: "C & C Helck" <pp002531@...>
      > 3. It seems like the person who's not at the keyboard is just watching the
      > other type. This is boring. The other day I found myself telling the
      person
      > where to move their mouse and what to type. I'm surprised she didn't kill
      me.

      In my experience, pairing works best when the two people involved are
      already comfortable with each other and like working together AND when they
      have similar levels of understanding of the code in question. When one
      person knows a lot more than the other, then you tend to see the above,
      because the person with the knowledge will tend to want to do the typing. I
      suspect that's what happening with your team, since you had a lot of prior
      code ownership.

      There's a lot of this on my current team, so what we do is say that the
      driver has to be the one with the least amount of experience with the code
      being worked on. (Not the least programming experience, the least
      experience with the code in question.) Then the navigator is not allowed to
      touch the keyboard or dictate keystrokes. Instead, Navigator is supposed to
      explain what needs to be done and why, and Driver is supposed to figure out
      how to go do it, asking plenty of questions along the way.

      This takes a lot of patience and discipline because Navigator will "see" the
      solution and want to just type it in. (I'm easily the worst offender on my
      team, so I know how hard this is. :) ) Driver has to be aggressive and not
      let Navigator take the keyboard away until he understands what's going on.
      But, very quickly, Driver and Navigator's understanding will equalize.
      (It's amazing how quickly this happens... you'll see it within a 3-week
      iteration, two at worst, depending on the complexity of the code.)

      Once Driver and Navigator have reached rough parity, then you can go back to
      the standard form of pairing, where the roles aren't set in stone and the
      keyboard changes hands frequently. But until that happens, be disciplined
      about the Driver and Navigator roles. Otherwise you'll see "Navigator" do
      all the typing, and Driver will sit there and be frustrated and confused.

      > 4. I'm a bad example. I'm working on build scripts, I say to myself "No
      one
      > else knows this stuff, most of my time is spent downloading tools or
      > running long batch jobs. Why drag anyone else into this?".

      Because you want to be able to take a vacation. :) Seriously, what if you
      get hit by a truck? Wouldn't be better for someone else to learn how to do
      that before then? And if most of your time is spent waiting, the two of you
      can work on something else at the same time.

      Establish a culture where pairing is assumed, where anybody feels
      comfortable saying, "C, how come you're not pairing?" It's easier said than
      done, but if you can do it, then your team members will help you out when
      you're feeling like taking short-cuts.

      > 6. We're working on the second phase of a project who's first phase we
      just
      > completed. There's a lot of code ownership and tasks have been assigned
      > accordingly. So, if Joe worked on the Foo class, he and his partner will
      > make changes to Foo. Would it be better to encourage Joe to have nothing
      to
      > do with Foo at all? That way the two people really have to work together
      to
      > figure things out?

      This is a good idea, but it might be slower than having Joe be navigator
      directly. On the other hand, it would probably make pairing easier. If you
      do do this, make sure that Joe is available to answer questions and coach.

      Jim
    • Robert C. Martin
      ... Usually a pair forms because one developer asks another for help with his task. Sometimes a pair forms because one member wants to help another with his
      Message 2 of 4 , Sep 17, 2000
        > -----Original Message-----
        > From: C & C Helck [mailto:pp002531@...]
        > Sent: Saturday, September 16, 2000 9:52 PM
        > To: extremeprogramming@egroups.com
        > Subject: [XP] Having problems with Paired Programming
        >
        >
        > I'm trying to get my group to do paired programming and am
        > running into
        > resistence. Here's the problems that I see happening:
        >
        > 1. People have signed up for tasks, hence they want to do
        > them right now.
        > How does a pair decide who's task to work on?

        Usually a pair forms because one developer asks another for help with his
        task. Sometimes a pair forms because one member wants to help another with
        his task, and asks if he may be allowed. So pairs usually form around
        tasks. If a pair forms in some other way then the developers simply
        negotiate how much time they will each spend on their tasks.

        > 2. Social awkwardness. The second person often sits far away?

        Change your furniture. Do some pair programming demos so everyone sees how
        it is supposed to work. Encourage frequent passing of the keyboard. Pair
        with the shy ones yourself and encourage their participation.

        > 3. It seems like the person who's not at the keyboard is just
        > watching the
        > other type. This is boring. The other day I found myself
        > telling the person
        > where to move their mouse and what to type. I'm surprised she
        > didn't kill me.

        Try to engage your partner in the development. If they are being quiet,
        pass the keyboard to them.

        >
        > 4. I'm a bad example. I'm working on build scripts, I say to
        > myself "No one
        > else knows this stuff, most of my time is spent downloading tools or
        > running long batch jobs. Why drag anyone else into this?".

        Because everything you are doing can be done better with help. Everybody is
        the exception; so you can't let *anybody* be the exception.

        > 5. Our work environment really, really sucks. I'm hoping that
        > after a few
        > weeks I'll get buy in from the team about the concept and
        > then I can go to
        > management and argue for an open workspace.

        In the meantime, do what you can to improve the environment. Move the
        screens and keyboards to tables where pair programming is more convenient.
        Make sure pairs sit right next to each other rather than one in front and
        the other behind.

        > 6. We're working on the second phase of a project who's first
        > phase we just
        > completed. There's a lot of code ownership and tasks have
        > been assigned
        > accordingly.

        Don't assign tasks. Let people sign up for them. Or is that what you meant
        to say?

        > So, if Joe worked on the Foo class, he and his
        > partner will
        > make changes to Foo.

        Did Joe sign up for the task? Ask folks not to sign up for code they are
        familiar with; and instead to get help from the people who are.


        Robert C. Martin | "Uncle Bob" | Software Consultants
        Object Mentor Inc. | rmartin@... | We'll help you get
        PO Box 5757 | Tel: (800) 338-6716 | your projects done.
        565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
        Suite 135 | | www.XProgramming.com
        Vernon Hills, IL, | Training and Mentoring | www.junit.org
        60061 | OO, XP, Java, C++, Python|

        "One of the great commandments of science is:
        'Mistrust arguments from authority.'" -- Carl Sagan
      • sward@interliant.com
        3. It seems like the person who s not at the keyboard is just watching the other type. This is boring. The other day I found myself telling the person where
        Message 3 of 4 , Sep 18, 2000
          "3. It seems like the person who's not at the keyboard is just watching the

          other type. This is boring. The other day I found myself telling the person

          where to move their mouse and what to type. I'm surprised she didn't kill
          me."

          I recommend getting the team some Silly Putty (you can buy it in 5 pound
          boxes over the web). It gives the person who is not typing something to do
          with his/her fingers, but doesn't distract the eyes and mind from the code.
          Our team started doing it and we infected the entire department.
          Everyone's now addicted.

          Also, I found pair programming became more interesting when we wrote our
          tests first. A discussion would occur as to what conditions we should or
          shouldn't test for and how the code would interact with other objects in
          the system.
        Your message has been successfully submitted and would be delivered to recipients shortly.