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

Re: [XP] Re: Pair Programming Measures

Expand Messages
  • Daniel Wildt
    In my experience, pairing must come together with a purpose. We found that the team is learning much more when doing pairing sessions. We were able to improve
    Message 1 of 12 , Oct 12, 2012
    • 0 Attachment
      In my experience, pairing must come together with a purpose. We found that
      the team is learning much more when doing pairing sessions.

      We were able to improve much faster our business knowledge doing pairing
      sessions. Same thing happened with technical knowledge creation where
      people with more experience paired more often with people with less
      experience.

      The "ramp up" process had also a big benefit from pairing. Every new person
      on the team is asked to try to pair 100% of the time when touching
      production code. Which they start doing on day 1.

      Pairing was also very important integrating business analysts and
      developers.

      And everything started with Coding Dojos. Where developers could practice
      programming and also pairing, test automation, respect, they learn that
      they can learn and teach other people. They learn how to create knowledge
      while delivering a feature.

      -- Daniel Wildt - @dwildt <http://twitter.com/dwildt>


      On Thu, Oct 11, 2012 at 3:11 PM, Steven Gordon <sgordonphd@...> wrote:

      > Agile teams should try pairing because they have a problem with quality
      > and/or knowledge silos and believe it may help them address their problem.
      > And then they try it and retrospect on it to see if it helps and if not
      > whether they should try to do it better or abandon the idea. This goes for
      > other practices as well.
      >
      > Doing something because somebody else "proved" that it work for them is
      > backwards. Doing something because some manager tells them to do it
      > because somebody else "proved" that it work for them is double backwards.
      >
      > Metrics are so context-sensitive that they just do not translate from one
      > situation to another. They are useful for seeing if a specific team is
      > getting better over time, but they are not good for comparing teams or
      > deciding if a practice works well in general.
      >
      > The expense of taking the context-sensitivity out of metrics is only
      > warranted for things like drugs and medical procedures, not software
      > development.
      >
      > Agile opens the door for each team to take responsibility of using their
      > own metrics to improve their own process - promote that. Providing
      > guidelines and feedback for how to do that is conducive to agility. In my
      > opinion, attempting to do it generally it for all teams is prohibitively
      > expensive to do validly and inhibits the long term agility of individual
      > teams.
      >
      > Steven Gordon
      >
      > On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...
      > >wrote:
      >
      > > **
      > >
      > >
      > > Thank you Rob... my impression was that the quantitive metrics available
      > > are not establishing a strong case for pairing.
      > >
      > > I remain hopeful that some day we might have qualitative measures useful
      > > for making the case.
      > >
      > > _Marvin
      > >
      > >
      > > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...>
      > > wrote:
      > > >
      > > > The only quantitative metrics I recall reading about were done by
      > Laurie
      > > Williams, and were taken in an academic setting.
      > > >
      > > > She found that the defect rates were much lower, but the development
      > > time was a little higher. It was shown to be a net win.
      > > >
      > > > In my experience, paired development time is not slower, but faster,
      > for
      > > a whole list of qualitative, behavioral reasons. When it comes to
      > knowledge
      > > work (surgery, flying an airliner, writing production-ready code), on
      > > average, two people will complete two tasks faster together than
      > separately.
      > > >
      > > > I'd love it if someone could fund more industry research. I have plenty
      > > of hypotheses that need testing. ;-)
      > > >
      > > >
      > > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com"
      > <MarvinToll@>
      > > wrote:
      > > > >
      > > > > Has the dust ever settled on this topic? My understanding is that
      > > there is some consensus that quantitative metrics in this area are not
      > all
      > > that useful... however, there may be more validity to qualitative
      > measures.
      > > > >
      > > > > _Marvin
      > > > >
      > > >
      > >
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Ian Mitchell
      My experience has led me to the following: 1. The biggest source of errors is not understanding the problem before inventing the solution. Not understanding
      Message 2 of 12 , Oct 13, 2012
      • 0 Attachment
        My experience has led me to the following:
        1. The biggest source of errors is not understanding the problem before
        inventing the solution. Not understanding includes not thinking deeply
        enough and not spotting ambiguities. Two people discussing a problem often
        help clarify it and ensure that they understand its true width. Defects
        like this survive into production and hence are the most expensive.
        2. Always enforce pre- and post- assertion approaches.
        3. Then write the test harness so the criteria for a correct solution is
        agreed before much code is written.
        4. Another major factor is that if we make a typo we often do not see it
        [if it is compilable] because we see what we knew we wrote whereas someone
        else immediately sees that that is not what they would have written.
        5. Personality impacts pair programming - sometimes two people work
        effectively together but sometimes one person effectively just watches the
        other person - particularly if one is experienced and the other a newbie.
        6. Also if the code follows a familiar pattern the second member of the
        pair cannot contribute much.

        On 13 October 2012 11:47, Daniel Wildt <dwildt@...> wrote:

        > **
        >
        >
        > In my experience, pairing must come together with a purpose. We found that
        > the team is learning much more when doing pairing sessions.
        >
        > We were able to improve much faster our business knowledge doing pairing
        > sessions. Same thing happened with technical knowledge creation where
        > people with more experience paired more often with people with less
        > experience.
        >
        > The "ramp up" process had also a big benefit from pairing. Every new person
        > on the team is asked to try to pair 100% of the time when touching
        > production code. Which they start doing on day 1.
        >
        > Pairing was also very important integrating business analysts and
        > developers.
        >
        > And everything started with Coding Dojos. Where developers could practice
        > programming and also pairing, test automation, respect, they learn that
        > they can learn and teach other people. They learn how to create knowledge
        > while delivering a feature.
        >
        > -- Daniel Wildt - @dwildt <http://twitter.com/dwildt>
        >
        >
        > On Thu, Oct 11, 2012 at 3:11 PM, Steven Gordon <sgordonphd@...>
        > wrote:
        >
        > > Agile teams should try pairing because they have a problem with quality
        > > and/or knowledge silos and believe it may help them address their
        > problem.
        > > And then they try it and retrospect on it to see if it helps and if not
        > > whether they should try to do it better or abandon the idea. This goes
        > for
        > > other practices as well.
        > >
        > > Doing something because somebody else "proved" that it work for them is
        > > backwards. Doing something because some manager tells them to do it
        > > because somebody else "proved" that it work for them is double backwards.
        > >
        > > Metrics are so context-sensitive that they just do not translate from one
        > > situation to another. They are useful for seeing if a specific team is
        > > getting better over time, but they are not good for comparing teams or
        > > deciding if a practice works well in general.
        > >
        > > The expense of taking the context-sensitivity out of metrics is only
        > > warranted for things like drugs and medical procedures, not software
        > > development.
        > >
        > > Agile opens the door for each team to take responsibility of using their
        > > own metrics to improve their own process - promote that. Providing
        > > guidelines and feedback for how to do that is conducive to agility. In my
        > > opinion, attempting to do it generally it for all teams is prohibitively
        > > expensive to do validly and inhibits the long term agility of individual
        > > teams.
        > >
        > > Steven Gordon
        > >
        > > On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...
        > > >wrote:
        > >
        > > > **
        > > >
        > > >
        > > > Thank you Rob... my impression was that the quantitive metrics
        > available
        > > > are not establishing a strong case for pairing.
        > > >
        > > > I remain hopeful that some day we might have qualitative measures
        > useful
        > > > for making the case.
        > > >
        > > > _Marvin
        > > >
        > > >
        > > > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...>
        > > > wrote:
        > > > >
        > > > > The only quantitative metrics I recall reading about were done by
        > > Laurie
        > > > Williams, and were taken in an academic setting.
        > > > >
        > > > > She found that the defect rates were much lower, but the development
        > > > time was a little higher. It was shown to be a net win.
        > > > >
        > > > > In my experience, paired development time is not slower, but faster,
        > > for
        > > > a whole list of qualitative, behavioral reasons. When it comes to
        > > knowledge
        > > > work (surgery, flying an airliner, writing production-ready code), on
        > > > average, two people will complete two tasks faster together than
        > > separately.
        > > > >
        > > > > I'd love it if someone could fund more industry research. I have
        > plenty
        > > > of hypotheses that need testing. ;-)
        > > > >
        > > > >
        > > > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com"
        > > <MarvinToll@>
        > > > wrote:
        > > > > >
        > > > > > Has the dust ever settled on this topic? My understanding is that
        > > > there is some consensus that quantitative metrics in this area are not
        > > all
        > > > that useful... however, there may be more validity to qualitative
        > > measures.
        > > > > >
        > > > > > _Marvin
        > > > > >
        > > > >
        > > >
        > > >
        > > >
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > To Post a message, send it to: extremeprogramming@...
        > >
        > > To Unsubscribe, send a blank message to:
        > > extremeprogramming-unsubscribe@...
        > >
        > > ad-free courtesy of objectmentor.comYahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >



        --
        Regards
        Ian Mitchell, FIITP ITCP
        ICT and Management Consultant
        2/40 Sylvia Road
        St Heliers
        Auckland, New Zealand
        0064 9 5851580
        http://www.Mitchell.co.nz
        http://www.AboutIT.co.nz
        http://www.SoftwareAsAService.co.nz


        [Non-text portions of this message have been removed]
      • Tim Ottinger
        ... I don t quite understand the question. Are you asking about studies that suggest pairing is more effective? Or whether it s good to measure pair
        Message 3 of 12 , Oct 15, 2012
        • 0 Attachment
          > Has the dust ever settled on this topic?  My understanding is that there is some 
          > consensus that quantitative metrics in this area are not all that useful... 
          > however, there may be more validity to qualitative measures.


          I don't quite understand the question.

          Are you asking about studies that suggest pairing is more effective?
          Or whether it's good to measure pair programming as it happens? 



           
          Tim Ottinger <tottinge@...>
          http://industriallogic.com/
          http://agileotter.blogspot.com/
        Your message has been successfully submitted and would be delivered to recipients shortly.