RE: Pair Programming

So said  STEURS Stefan  on  12/23/2002 --------------------

<snip />
>> 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?

Perhaps not. I would say that as long as you were able to be effective and as long as the team feels that you're "available enough" for pairing, then I would think that there isn't much to be concerned about. Teams that do PP can still be flexible. In fact, PP is supposed to enable flexibility: if you can't show up for work, your partner can work with someone else and you can more onto another task.

>> 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 envy you your ability to rise that early. I couldn't do it consistently.

>> 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?

Well, the more pair programming the team does, the more pair programming it *can* do, because the more flexible the pairs can be: a team on which anyone can be effective doing anything enables the maximum amount of pair programming. A good way to get to that point is to do a lot of pairing.

>> 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?

The usual experience with walkthroughs is that there's never time to do them, so they silently stop happening.

>> 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?

It could work, but it wouldn't be nearly as good as pairing all the time, because pairing is more than just continuous code review: it's mentoring, peer pressure to do the right thing and so on.

>> 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?

The team lead was convinced that we would go twice as quickly working solo as pairing. She just didn't understand. She found out that we went slightly faster working solo, until quality began to drop; then we slowed down. Then I got the hell out of there. Then they slowed down considerably.


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.




------------------------ 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/