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

Pair programming sucks. was Re: [XP] Pair programming vs. Mentoring in a pair

Expand Messages
  • Jiva DeVoe
    Pair programming sucks. However, it sucks less than programming alone. :) We re in the midst of an XP project currently, and I would have to say the biggest
    Message 1 of 8 , Apr 1, 2001
      Pair programming sucks.

      However, it sucks less than programming alone. :)

      We're in the midst of an XP project currently, and I would have to say
      the biggest challenge we've had has been pair programming. Partially,
      this is due to one of the coders (not me this time ;D) being a cowboy
      coder. Another problem is that we have an odd number of coders, thus,
      resulting in problems there. However, that said, here's some
      observations:

      1) The code produced by pairs is always of at *least* equal or better
      quality than that produced by loners. In some cases, loner code can
      achieve the same quality as pair produced code, but the pair produced
      code is at least *consistantly* of good quality.

      2) The productivity of pairs is similar to 1 above. Where in many
      cases you would think that two single coders might produce twice as
      much code as two paired coders, this is actually not the case, because
      the pairs tend to be able to code for longer periods. That is, when
      one gets tired, the other can take over.

      3) Required pairing *does* cut down on the ability of individuals to
      go home at night and continue work on the system remotely. Take this
      as a benefit or a deficit. 'Sup to you.

      4) Pairing increases adherance to the coding standard, and thus,
      easier integration.

      5) Pairing increases general knowledge of all aspects of the system
      and spreading of that knowledge among the team. (The dye-in-water
      affect discussed in one of the XP books.)

      6) The code produced by pairs is instantaneously peer reviewed, AND
      peer reviewed thoroughly. If we DON'T pair program, we do peer review
      seperately, and that takes up AT LEAST 2 coders worth of time. With
      pair programming, I don't need to do seperate peer review. We have
      one coder who just doesn't pair well. He consistantly codes alone,
      and then asks other members of the team to "peer review" his code.
      Needless to say, some of the team resents this because it wastes their
      time. If he'd just pair programmed it in the first place, it'd be
      peer reviewed already right?

      Which brings me to the MAIN reason I think pair programming is
      important. And that is PEER REVIEW. I honestly want to know here,
      does ANYONE know of ANY cases when Peer Review of code *outside* of
      pair programming *actually* works?

      I mean, this brings up what I think is the key point here productivity
      wise. In order to accept pair programming as a requirement, you have
      to accept that peer review of code is a requirement. We all know,
      studies have shown, _the_ most consistant way to reduce design and
      code-level bugs is through peer review.

      I have attempted to put in place peer review sessions on SEVERAL
      projects, but have always failed in the long term because A) reviewers
      don't really care about other people's code, and thus don't review it
      closely enough. B) coders hate to review code in general, and thus,
      it's the FIRST thing to go when time gets tight.

      IF you legitimately believe peer review is important to quality code,
      than the only way to do this effectively in my experience, is through
      pairing (or alternatively, open-sourcing, but even this is not 100%
      effective.)

      On the other hand, if you're willing to forsake peer review, pairing
      may or may not be more productive, but you take your life into your
      hands there.

      I'd be interested in hearing stories of peer review that actually
      worked effectively *outside* of pair coding.

      I'd also be interested in hearing of anyone's ideas on how to solve
      the "odd number of coders" problem I have. (Aside from hiring another
      coder. ;D)



      --
      Jiva DeVoe
      VP of Software Development
      Opnix, Inc. - http://www.opnix.com
    • Phlip
      ... My personal loner code is typically excellent on dimension X, but sucky on dimension Y. PairProgramming puts more area under the curve. ... While pairing I
      Message 2 of 8 , Apr 2, 2001
        Proclaimed Jiva DeVoe from the mountaintops:

        > 1) The code produced by pairs is always of at *least* equal or better
        > quality than that produced by loners. In some cases, loner code can
        > achieve the same quality as pair produced code, but the pair produced
        > code is at least *consistantly* of good quality.

        My personal loner code is typically excellent on dimension X, but sucky on
        dimension Y. PairProgramming puts more area under the curve.

        > 2) The productivity of pairs is similar to 1 above. Where in many
        > cases you would think that two single coders might produce twice as
        > much code as two paired coders, this is actually not the case, because
        > the pairs tend to be able to code for longer periods. That is, when
        > one gets tired, the other can take over.

        While pairing I far less frequently nip out to read the list server(s).

        > 3) Required pairing *does* cut down on the ability of individuals to
        > go home at night and continue work on the system remotely. Take this
        > as a benefit or a deficit. 'Sup to you.

        Night is for spiking & research.

        > 4) Pairing increases adherance to the coding standard, and thus,
        > easier integration.

        If you mean the Esthetic Coding Standard, so what? It only exists to
        facilitate pairing and code sharing, so this is a tautology.

        If you mean the Technical Coding Standard, I'l admit that others can learn
        from my awesomeness.

        > 5) Pairing increases general knowledge of all aspects of the system
        > and spreading of that knowledge among the team. (The dye-in-water
        > affect discussed in one of the XP books.)

        Best situation: A domain expert paired with a coding expert. "Navigation" now
        actually means piloting the whole ship thru the harbor.

        Other best situation: Some other pair beating up on the code those two wrote.

        > Which brings me to the MAIN reason I think pair programming is
        > important. And that is PEER REVIEW. I honestly want to know here,
        > does ANYONE know of ANY cases when Peer Review of code *outside* of
        > pair programming *actually* works?

        Well, I never wrote anything that anyone would have ever needed to review
        (except to learn from it) so I wouldn't know.

        --
        Phlip phlip_cpp@...
        ============== http://phlip.webjump.com ==============
        -- Proud victim of the dreaded boomerang effect --
      • Anders Bengtsson
        ... Other people have already addressed these issues, but here s my take on it. Although, as I have experienced, you do learn a lot even when pairing with a
        Message 3 of 8 , Apr 2, 2001
          --- Martin Andrews <martin@...> wrote:

          > I recently worked with a client where I used pair
          > programming as
          > a technique for mentoring a newbie. It worked well
          > for skills
          > transfer but was personally very slow and
          > frustrating to create
          > new functionality in the system.
          >
          > I found that the time spent at the keyboard was
          > about 95/5 in
          > favour of the newbie. I did that deliberately so
          > that they would
          > pick up the skills (which is why I was there), and
          > it achieved its
          > purpose well.
          >
          > If working on a project as a developer (instead of
          > as a mentor), I
          > think I would find it frustrating to spend extended
          > pair-programming
          > time with other staff that have a large skill
          > difference to me. I
          > would like to be able to work with someone of
          > similar skills where
          > 'drive' time was closer to 50/50.
          >
          > Comments?

          Other people have already addressed these issues, but
          here's my take on it.
          Although, as I have experienced, you do learn a lot
          even when pairing with a less skilled programmer, it
          can still be very frustrating. One great reason I've
          found for accepting the frustration is that it would
          be far more frustrating to watch the same person make
          a mess out of the code on their own.
          But it can also be great fun to pair with them, if you
          manage to keep yourself from feeling stressed out by
          the slow (visible) progress.

          If you didn't take the time to help the new
          programmers get up to speed, i guess you know who's to
          blame when they fail. (been there, done that ;-)

          /Anders

          =====
          __________________________________________________
          Anders Bengtsson ndrsbngtssn@...
          Stockholm, Sweden

          _____________________________________________________
          Do You Yahoo!?
          Ditt_namn@... - skaffa en gratis mailadress på http://mail.yahoo.se
        • Fred Nenad Brkich
          Hi All, Just a cultural comment ... on a social phenomenon ... ... I have long noticed that different cultures have different notions of physical space .
          Message 4 of 8 , Apr 2, 2001
            Hi All,

            Just a 'cultural' comment ... on a social phenomenon ...

            > > The jury is still out on pair programming - sounds good, but
            > > this will be a real culture shock for most folk - I'd think
            > > that most managers would need some convincing that this would
            > > speed up development times (although I'm personally confident
            > > that some degree of pair programming would have advantages -
            > > e.g. mentoring, knowledge-sharing).

            I have long noticed that different cultures have different notions
            of 'physical space'. Some cultures work on a consensus type system,
            say S.E.Asian cultures, other cultures work on an individual system,
            where rewards go to the pushiest individual. So I wonder where this
            'pair programming' idea comes from in the Anglo-American context? And
            I wonder how succesful it'll be in a culture which is fundamentally
            based on dog-eat-dog individualism? Anyway, if it's all such a good
            idea how come it has only come along now? Couldn't be because the
            American Hot Shots (err ... "genius programmers") haven't heard that
            we already tried it and it didn't work.

            I once tried ... ahem ... "pair toy train-driving" with a cute
            little five year old ... and I didn't get to drive at all! Just
            did a lot of "mentoring" .... ;)

            :)
            freddo








            >
            > [snip]
            >
            >
            > I recently worked with a client where I used pair programming as
            > a technique for mentoring a newbie. It worked well for skills
            > transfer but was personally very slow and frustrating to create
            > new functionality in the system.
            >
            > I found that the time spent at the keyboard was about 95/5 in
            > favour of the newbie. I did that deliberately so that they would
            > pick up the skills (which is why I was there), and it achieved its
            > purpose well.
            >
            > If working on a project as a developer (instead of as a mentor), I
            > think I would find it frustrating to spend extended pair-programming
            > time with other staff that have a large skill difference to me. I
            > would like to be able to work with someone of similar skills where
            > 'drive' time was closer to 50/50.
            >
            > Comments?
            >
            >
            >
            > Martin Andrews
            >
            >
            > Senior Software Engineer
            >
            > Object Oriented Pty. Ltd. Phone: +61 3 9866-5266
            > Level 11, 484 St Kilda Rd Fax: +61 3 9866-5211
            > Melbourne Victoria 3004 Mobile: +61 414 599 054
            >
            > http://www.oopl.com.au
            >
            >
            >
            > ------_=_NextPart_001_01C0BB03.1C93ACF0
            > Content-Type: text/html; charset=US-ASCII
            > Content-Transfer-Encoding: 7bit
            >
            > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
            > <HTML>
            > <HEAD>
            > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
            > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
            > <TITLE>Pair programming vs. Mentoring in a pair</TITLE>
            > </HEAD>
            > <BODY>
            >
            > <P><FONT SIZE=2>Hi all,</FONT>
            > </P>
            > <BR>
            >
            > <P><FONT SIZE=2>> -----Original Message-----</FONT>
            > <BR><FONT SIZE=2>> From: Jason Grant [<A HREF="mailto:jason.grant@...">mailto:jason.grant@...</A>]</FONT>
            > <BR><FONT SIZE=2>> Sent: Sunday, 1 April 2001 11:04 </FONT>
            > <BR><FONT SIZE=2>> To: ajug-victoria@yahoogroups.com</FONT>
            > <BR><FONT SIZE=2>> Subject: Re: [ajug-victoria] Extreme Java Programming</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>[snip]</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>> The jury is still out on pair programming - sounds good, but </FONT>
            > <BR><FONT SIZE=2>> this will be a real culture shock for most folk - I'd think </FONT>
            > <BR><FONT SIZE=2>> that most managers would need some convincing that this would </FONT>
            > <BR><FONT SIZE=2>> speed up development times (although I'm personally confident </FONT>
            > <BR><FONT SIZE=2>> that some degree of pair programming would have advantages - </FONT>
            > <BR><FONT SIZE=2>> e.g. mentoring, knowledge-sharing).</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>[snip]</FONT>
            > </P>
            > <BR>
            >
            > <P><FONT SIZE=2>I recently worked with a client where I used pair programming as </FONT>
            > <BR><FONT SIZE=2>a technique for mentoring a newbie.  It worked well for skills </FONT>
            > <BR><FONT SIZE=2>transfer but was personally very slow and frustrating to create </FONT>
            > <BR><FONT SIZE=2>new functionality in the system.</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>I found that the time spent at the keyboard was about 95/5 in </FONT>
            > <BR><FONT SIZE=2>favour of the newbie.  I did that deliberately so that they would </FONT>
            > <BR><FONT SIZE=2>pick up the skills (which is why I was there), and it achieved its </FONT>
            > <BR><FONT SIZE=2>purpose well.</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>If working on a project as a developer (instead of as a mentor), I </FONT>
            > <BR><FONT SIZE=2>think I would find it frustrating to spend extended pair-programming </FONT>
            > <BR><FONT SIZE=2>time with other staff that have a large skill difference to me.  I </FONT>
            > <BR><FONT SIZE=2>would like to be able to work with someone of similar skills where </FONT>
            > <BR><FONT SIZE=2>'drive' time was closer to 50/50.</FONT>
            > </P>
            >
            > <P><FONT SIZE=2>Comments?</FONT>
            > </P>
            > <BR>
            > <BR>
            >
            > <P><FONT SIZE=2>Martin Andrews</FONT>
            > <BR><FONT SIZE=2> </FONT>
            > </P>
            >
            > <P><FONT SIZE=2>Senior Software Engineer</FONT>
            > <BR><FONT SIZE=2> </FONT>
            > <BR><FONT SIZE=2>Object Oriented Pty. Ltd.        Phone:  +61 3 9866-5266</FONT>
            > <BR><FONT SIZE=2>Level 11, 484 St Kilda Rd        Fax:    +61 3 9866-5211</FONT>
            > <BR><FONT SIZE=2>Melbourne  Victoria  3004        Mobile: +61 414 599 054</FONT>
            > <BR><FONT SIZE=2> </FONT>
            > <BR><FONT SIZE=2><A HREF="http://www.oopl.com.au" TARGET="_blank">http://www.oopl.com.au</A></FONT>
            > </P>
            > <BR>
            >
            >
            > <br>
            >
            > <!-- |**|begin egp html banner|**| -->
            >
            > <table border=0 cellspacing=0 cellpadding=2>
            > <tr bgcolor=#FFFFCC>
            > <td align=center><font size="-1" color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
            > </tr>
            > <tr bgcolor=#FFFFFF>
            > <td width=470><a href="http://rd.yahoo.com/M=162801.1342280.2934645.1280039/D=egroupmail/S=1700006764:N/A=599121/*http://www.knowledgestorm.com/jump_white.html?c=Yahoo&n=eLert_ComputersInternet_ProgrammingLang_WhiteGridOptions&t=ad" target="_top"><img width=468 height=60 src="http://us.a1.yimg.com/us.yimg.com/a/kn/knowledge_storm/elerts_n_whitegridoptions.gif" alt="Click Here to Find Software Faster" border=0><br>Click Here to Find Software Faster</a></td>
            > </tr>
            > <tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=162801.1342280.2934645.1280039/D=egroupmail/S=1700006764:N/A=599121/rand=393016354"></td></tr>
            > </table>
            >
            > <!-- |**|end egp html banner|**| -->
            >
            >
            >
            > <br>
            > <tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt>
            > </br>
            >
            > </BODY>
            > </HTML>
            > ------_=_NextPart_001_01C0BB03.1C93ACF0--
            >
          • Fred Nenad Brkich
            Hi, I am struck by the underlying issue (or one of them). Do people make more progress, become more productive working in groups, than when working alone? Will
            Message 5 of 8 , Apr 2, 2001
              Hi,

              I am struck by the underlying issue (or one of them). Do people make
              more progress, become more productive working in groups, than when
              working alone? Will two jewellers working together be more productive
              than working alone? Recall many historical examples of art studios where
              "master" craftsmen worked with numerous assistants! On the other hand
              I recall a critique of the Japanese "collegial" approach to manufacture,
              stating that it worked very well for implementing technological
              solutions, but worked poorly for more creative inventive kinds of work,
              where American (individualism) worked better. Of course(!) the Japanese
              were famous for underpinning their systems with a "no blame", "no
              fault" approach to handling responsibility - people weren't sacked the
              moment the year's figures didn't go well. CEO's shouldered responsibility.
              Rewards were shared. The mirror opposite of the individualistic
              approach ... where finding individuals to blame and reward is the
              sine qua non of management practice and employees are merely expendable
              "resources".

              Pair programming is an interesting idea, but may it not be the
              "(collegiate) exception that proves the (individualistic) rule"
              in Aussie/Anglo/American business culture? I have no clear answer.


              > Interesting observation. Not sure about the 'timing' that you mention -
              > my first encounter with pair programming was in 1990. I was working for
              > the MITRE Corporation in the US in Virginia in their AI Lab. Everyone had
              > a MAC or a Sparc on their desk in their small private office, but the
              > really useful LISP Machines were out in a large public 'lab' space. There
              > were more developers than machines sometimes.

              Of course, if there were fewer machines ... ;)

              Regards
              Fred
            • Ron Jeffries
              ... Those of us who do it have a clear answer. But we re not telling. Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
              Message 6 of 8 , Apr 3, 2001
                Responding to Fred Nenad Brkich (01:33 PM 4/3/2001 +1000):
                >Pair programming is an interesting idea, but may it not be the
                >"(collegiate) exception that proves the (individualistic) rule"
                >in Aussie/Anglo/American business culture? I have no clear answer.

                Those of us who do it have a clear answer. But we're not telling.

                Ronald E Jeffries
                http://www.XProgramming.com
                http://www.objectmentor.com
              • Dossy
                ... Do you have any non-code writing tasks that the team must do? Could the odd-person out work on those tasks? (Usually, documentation tasks come to mind.)
                Message 7 of 8 , Apr 3, 2001
                  On 2001.04.01, Jiva DeVoe <jiva@...> wrote:
                  > I'd also be interested in hearing of anyone's ideas on how to solve
                  > the "odd number of coders" problem I have. (Aside from hiring another
                  > coder. ;D)

                  Do you have any non-code writing tasks that the team must do? Could
                  the odd-person out work on those tasks? (Usually, documentation tasks
                  come to mind.)

                  How about triplet programming, still with one person driving and
                  two passengers? Or, siamese programming, where two people drive
                  and one person acts as the passenger. The two drivers split
                  responsibility (one writes tests, the other writes code to make
                  tests pass) and the passenger watches the two. The passenger can
                  take the place of either driver when appropriate.

                  These are just some initial suggestions without knowing more details
                  about your particular shop, project, or team culture. If you share
                  those details with us, perhaps there are more suggestions available ...

                  - Dossy

                  --
                  Dossy Shiobara mail: dossy@...
                  Panoptic Computer Network web: http://www.panoptic.com/
                Your message has been successfully submitted and would be delivered to recipients shortly.