Re: Pair Programming

Hi Stefan,

Thank you for your postings on this topic.  I've seen several discussions
about PP on the XP list over the last few months but none of them triggered
the thought pattern yours sent me into.  Several of the posters have said
that PP is one of the hardest XP practices to get adopted.  The discussions
have most often focused on the Productivity question, e.g., is productivity
higher or lower using PP than solo programming.  I've not felt comfortable
that this was really an issue.  Laurie Williams research shows a slight drop
in productivity, albeit with higher quality output, but as Glen's noted, the
drop Williams reported isn't statistically significant.  So that strikes me
as, as J. B. put it, a Red Herring, i.e., an argument that's meant to divert
attention away from the real issue.

In thinking about this from the perspective you propose, it occurs to me
that PP runs head-long into the HR arena.  Not only does it cause us to ask
questions about core Benefits such as flex time, but it then leads
immediately into a question about its impact on the Performance Planning /
Appraisel process.  This then calls into question its impact on the
liklihood that a company's practices in this area are fair, consistent, and
perhaps even legal (depending on local laws).  The root issue is one that
the HR community struggles with, at least in my experience here in the U.S..
Succinctly, the question is "what should HR policies be in an environment
where we want / need to foster team work and must also recognize that
individuals perform at various levels?"  Throw in some Union or National
Labor Laws, and this could get really sticky.  Ugh.  So I wonder, is this
the real issue behind those Red Herring arguments that get tossed into the
ring.  Could be, I think.  And if it is, I'd expect both development and
management to be tossing them.  The discussions I've seen tell me they are
both tossing them, too.  In short, if I were a manager, or manager of
managers, trying to figure out how to introduce XP in a way that gave it the
best shot at being widely adopted in my environment, PP would not be one of
the first practices I'd insist on.  I'm not saying it's not the most
important.  In the long term, it probably is.  I'm saying my perception's
that it's probably the most dangerous from an organizational perspective
when I look at it from this angle.  It would take a lot of motivation in the
environments I've worked in to tackle modifications to the HR processes to
support a new software development practice.  (Remember that I work in IT
environments where the IT staff is a small percentage of the total.)

Thanks again for the thought provoking topic.

Best regards and Happy Holidays!
Bill

Stefan Steurs wrote:

> > J. B. Rainsberger wrote:

> > >
> > >One question I have in relation to Pair Programming (perhaps I
> > >misunderstand
> > >how to organise it).
> > >
> > >In our organisation there is a lot of flexibility for
> > working hours.  Some
> > >people start at 7h00 am, some at 11h00 am, some finish
> > around 15h30, some
> > >work till 20h30.
> > >
> > >Are their hard constraints in pair programming that pairs
> > always have to
> > >work the same working hours?  How does one arrange that if
> > there is no
> > >"core
> > >time".
> >
> > I feel that this is one of those areas where the members of
> > the team have to want to do What's Best For The Project in
> > order to achieve maximum benefit.
>
> Perhaps this is an easy statement to make but let's look at "my"
situation.
> During the week that I don't have to bring the kids to school I'm at work
at
> 7h00 am and work until something like 17h30 pm.
> When I bring my kids to school I cannot be at work earlier than 9h00 am
and
> usually it's more like 9h20.
>
> Do I have any choice in taking my kids to school?  No.
>
> Do I like to start at 7h00 am?  Yes.  I avoid all the traffic jams and
that
> saves me 1h00 of aggrevation a day.
>
> But What's best for the project is at odds with What's best for the
family.
> Do I really have a choice?
>
> >
> > I am speaking as an individual that generally hates starting
> > work early. When I worked on an XP project, I worked
> > 8h15-16h30, which meant waking up at 6h00, and I dearly love
> > my sleep. Still, in order to get maximum benefit for the
> > team, I made a point of showing up either at 8h15 or 9h00,
> > and our team's core time was 9h00-15h45.
>
> I love my bed as well but I wake up nearly every day at 5h45.
> >
> > I realize that this doesn't answer your question, and I'm
> > sorry about that. I see Pair Programming and Wildly Flexible
> > Hours as mutually contradictory. If there isn't enough
> > pair-time in the day to write the code and there is more than
> > enough alone-time in the day to cover the one-person tasks,
> > then the team needs to choose whether to allow solo
> > programming or enable more pair programming.
>
> The question is then "How do we enable more pair programming?"  I don't
see
> how.
> Does anyone on this list have ideas about this?
> >
> > To the extent that the team is able to enable more pair
> > programming, it will have the tendency to do so. Beyond that,
> > it will have to make a choice, understanding that less pair
> > programming leads directly to less quality.
>
> Perhaps there are other practices that can regain some of that quality?
> Would a walkthrough help, e.g. developer that was not paired walks through
> the code with peer when peer arrives?
> >
> > If the team wants to win, it will find a way. I think that
> > that value is ultimately more important than pair
> > programming, but should not be recommended unless the team
> > has seen how powerful pair programming can be.
>
> In the testing I've organised and planned, I've always looked at business
> needs/operational profiles, programming/design complexity, tester's
> capability, ... and then determine the critical/risky pieces that need to
be
> covered most.  Isn't this possible for pair programming as well.  I guess
> there must be pieces of code that are not so critical and risky so they
> would be ideal candidates for single programming while other absolutely
> require pair programming.  Could this work?
> >
> > PS: my "team" chose PP as the first practice to drop. XP was
> > gone within five weeks.
>
> What was their justification/motivation for dropping it?
> >
> > J. B. Rainsberger,
> > President, Diaspar Software Services
> > Let's write software that people understand.
> > http://www.diasparsoftware.com/
> > telephone: +1 416 791-8603
> > All correspondence (c) 2002 Diaspar Software Services.
> > If you want to use it, just ask; don't steal.
>
> Regards, Stefan Steurs.
>
>
> ____
>
> This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender
by reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
>
> Nothing in this e-mail message amounts to a contractual or legal
commitment on the part of EUROCONTROL unless it is confirmed by
appropriately signed hard copy.
>
> Any views expressed in this message are those of the sender.
>
>
>
>
> To unsubscribe from this group, send an email to:
> extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

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