'Re: [XP] Re: Pair Programming Measures'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       extremeprogramming
Subject:    Re: [XP] Re: Pair Programming Measures
From:       Ian Mitchell <Ian () Mitchell ! co ! nz>
Date:       2012-10-14 1:18:35
Message-ID: CAJc=uiu4zvnDXUaRjd-uRy56bSD4+RqWbk5CW1yLrr8iW0zVTg () mail ! gmail ! com
[Download RAW message or body]

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@gmail.com> 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@gmail.com>
> 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@gtcgroup.com
> > >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@eGroups.com
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@eGroups.com
> >
> > 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]



------------------------------------

To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/extremeprogramming/join
    (Yahoo! ID required)

<*> To change settings via email:
    extremeprogramming-digest@yahoogroups.com 
    extremeprogramming-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic