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

Staying in Pair

Expand Messages
  • Glew, Andy
    I have already posted describing how I am leading a team of 2 - myself and another programmer - and trying to implement XP practices, including test first
    Message 1 of 7 , Nov 9, 2001
    • 0 Attachment
      I have already posted describing how I am
      "leading" a team of 2 - myself and another
      programmer - and trying to implement XP
      practices, including test first and
      pair programming.



      We started out pair programming, at my insistence,
      overcoming my partner's initial resisteance. To my
      surprise, within a few days, he was bought into
      pair programming. But, recently, we have been pairing
      less and less. We still sit next to each other,
      and I still drag him over to look at my laptop as much
      as possible, but Tom always seems to find excuses
      to work on something else, independently.

      I find this disappointing, since I thought, and Tom seemed
      to agree, that pair programming was working well initially.
      But he continues to say things like "pair on the important
      stuff, but work independently - parallelize - on less important
      stuff." So, of course, the bugs just move into that code.

      Our lack of success pair programming may be related to
      us both using our own laptops. At first it worked pretty well
      - he might be driving on his machine while writing the test,
      while I had the class definition and Makefile (working in C++,
      lots of Makefile changes in refactoring) and cvs windows
      open, bouncing back and forth. But, lacking a positive
      will to cooperate, the separate machines make it possible
      to sit next to each other without pairing.
      Maybe this is the value in the original XP's insistence
      on "one display, one keyboard, two programmers".

      As usual, I invite comments from more experienced XPers.



      Ditto other XP practices like test first and refactoring.

      Again, Tom pays lip service, but I find that I am pushing the
      tests almost totally myself. Frankly, it gets frustrating, as I
      write the tests and Tom goes off to code independently.

      Similarly refactoring: I'm trying to strictly refactor, retaining
      semantic equivalence, but Tom takes the usual shortcuts
      that result in thrashing.

      Overall, I am more and more persuaded that XP, PP, TF and RF
      are the way to go, but I am frustrated at being the only practitioner
      in my "team".

      Frustrated to the point where I have considered abandoning, not XP,
      or the project, but the team - essentially "firing" Tom, taking him off
      the project. But, I will not be able to get any replacement soon.
      And, it is useful to have somebody else to work with, if only because
      I can regularly drag him over to my screen, maybe 5 minutes out
      of the hour, to review what I have done. Just frustrating, because I
      have this sense that more regular pairing would be even more
      productive.



      ===


      A friend has the following hypothesis about XP, and pair programming
      in particular: in a company that does competitive ranking and rating,
      pair programming is a threat to the average engineer. He knows that
      if he pairs with the really smart guy one cubicle over, it will be obvious
      that he is not as capable; and, if everyone works only 40 hours per
      week, then the average guy can't work more hours to attain the same
      absolute production.

      Again, comments solicited.
    • Bryan Dollery
      Andy Glew wrote ... You sound unhappy. Change that, fire Tom. You ll be more productive alone, and happy. Bryan The difference between me and the other
      Message 2 of 7 , Nov 9, 2001
      • 0 Attachment
        Andy Glew wrote
        > <snip/>

        You sound unhappy. Change that, fire Tom. You'll be more productive alone,
        and happy.

        Bryan

        The difference between me and the other surrealists is that I'm a
        surrealist.
        - Dali

        b r y a n d o l l e r y | c e o
        c h a o s e n g i n e e r s
        +64 (0)21 330607

        http://www.ChaosEngineers.co.nz


        [Non-text portions of this message have been removed]
      • carlton.nettleton@defenseweb.com
        It is hard to do XP with someone who is not interested or difficult. Perhaps you can find someone more receptive to learn? That said, I have had a similar
        Message 3 of 7 , Nov 9, 2001
        • 0 Attachment
          It is hard to do XP with someone who is not interested or difficult.
          Perhaps you can find someone more receptive to learn? That said, I
          have had a similar experience as you in my work environment. Here is
          what I can share.

          One way to solve the pair programming problem is stop "your" work and
          only pair on "his" work. When you are done, you both pair on "your"
          work. Sounds like you also identified another problem...get both of
          you on one computer. Its hard to wander off when you use one
          machine.

          Test first is a hard thing to do with someone who does not like
          testing. I have had mixed success with test first when pairing.
          Usually when I drive, I TFD. If I am not, then I usually talk out
          the function or sub with my partner, say how we can test it and write
          the code in the approrpiate library. Then we write the test before
          using the fucntion or sub in our "real" code. Not exactly test
          first, but then again, its not test last.

          For myself refactoring is a similar experience. The best time to
          refactor is right after the test runs to completion. Look at your
          code and think of ways to make it simplier. In my case, usually this
          means taking over the keyboard for a minute and then giving it back
          to the driver. Refactoring just takes a few minutes and does not
          interupt the flow.
        • kevinxp@qualitycode.com
          ... Pairing requires discipline. Sometimes you might have a coach circling around, constantly asking in a friendly tone why aren t you pairing? Otherwise,
          Message 4 of 7 , Nov 9, 2001
          • 0 Attachment
            --- In extremeprogramming@y..., "Glew, Andy" <andy.glew@i...> wrote:
            > But, recently, we have been pairing less and less.

            Pairing requires discipline. Sometimes you might have a coach circling around,
            constantly asking in a friendly tone "why aren't you pairing?" Otherwise, it's up
            to peer pressure to enforce it. With just two people in the group, you're half
            the peer pressure. And from the sound of it, you're the only one with real
            motivation to do pairing.

            > Tom always seems to find excuses
            > to work on something else, independently.

            As Dave suggested, you might need to find out what's going on in Tom's head.
            Does he really believe that pairing is not good for the project? Or not good for
            him professionally? Or personally? Or does he want to pair but just doesn't have
            enough motivation? Or it's just a habit that isn't yet second nature for him?

            > stuff, but work independently - parallelize - on less important
            > stuff." So, of course, the bugs just move into that code.

            That may be something you can use. More bugs == bad. Bad == avoid doing it.

            > Ditto other XP practices like test first and refactoring.

            Ditto my answer answers.

            > Frustrated to the point where I have considered abandoning, not XP,
            > or the project, but the team - essentially "firing" Tom, taking him off
            > the project.

            Talk with him first. Find out what's going on. Perhaps saying "we MUST pair,
            refactor, test-first, etc." would be enough motivation, at least to get him to
            the point where it's a solid habit. How does Tom's boss feel (if that's not you)?
            How does your boss feel?

            > A friend has the following hypothesis about XP, and pair programming
            > in particular: in a company that does competitive ranking and rating,
            > pair programming is a threat to the average engineer. He knows that
            > if he pairs with the really smart guy one cubicle over, it will be obvious
            > that he is not as capable; and, if everyone works only 40 hours per
            > week, then the average guy can't work more hours to attain the same
            > absolute production.

            Probably true. I think pairing is threatening to many people even without
            competitive ranking being in the picture.

            Kevin
          • C. Keith Ray
            ... What would happen if your individual laptops were taken away, and you two only had a single machine on which to program...? Perhaps you could keep your
            Message 5 of 7 , Nov 9, 2001
            • 0 Attachment
              on 11/9/01 7:48 AM, Glew, Andy at andy.glew@... wrote:

              > Our lack of success pair programming may be related to
              > us both using our own laptops. At first it worked pretty well
              > - he might be driving on his machine while writing the test,
              > while I had the class definition and Makefile (working in C++,
              > lots of Makefile changes in refactoring) and cvs windows
              > open, bouncing back and forth. But, lacking a positive
              > will to cooperate, the separate machines make it possible
              > to sit next to each other without pairing.
              > Maybe this is the value in the original XP's insistence
              > on "one display, one keyboard, two programmers".

              What would happen if your individual laptops were taken away, and you two
              only had a single machine on which to program...?

              Perhaps you could keep your email and company intranet access on
              several-years-old PCs or iMacs with very little RAM and little free disk
              space, so you would not be tempted to install your development environments
              on them.
            • Dale Emery
              Hi Andy, ... You can generalize that beyond XP: A company that does competitive ranking and rating is a threat to the average engineer (and to a lot of other
              Message 6 of 7 , Nov 9, 2001
              • 0 Attachment
                Hi Andy,

                > A friend has the following hypothesis about XP, and pair programming
                > in particular: in a company that does competitive ranking and
                > rating, pair programming is a threat to the average engineer.

                You can generalize that beyond XP: A company that does competitive
                ranking and rating is a threat to the average engineer (and to a lot
                of other people).

                Dale
              • Dale Emery
                Hi Andy, ... If everything you re writing is to satisfy a customer need, isn t it all important stuff? Dale
                Message 7 of 7 , Nov 9, 2001
                • 0 Attachment
                  Hi Andy,

                  > But he continues to say things like "pair on the important
                  > stuff, but work independently - parallelize - on less important
                  > stuff."

                  If everything you're writing is to satisfy a customer need, isn't it
                  all important stuff?

                  Dale
                Your message has been successfully submitted and would be delivered to recipients shortly.