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

Re: [XP] Re: Pair Programming Measures

Expand Messages
  • 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 1 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 2 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.