Re: "Winning" the pair programming discussion

(1)
Ask the person what the difference is between working on six tasks at once and taking a week to finish, and working on three tasks at once and taking a half-week to finish. Here, you assume that the pair works as quickly and effectively as the solo programmers. Then say, "I've noticed that I get things done more quickly when I pair. I can't put my finger on it, but that's what I observe. I don't look a gift horse in the mouth -- I just keep pairing."

(2)
Ask the person to tell you the story of the last time he was called back while on vacation to fix a problem only he could solve because he was The One Person Who Knew. If you're lucky, the story will be very elaborate and he will be very upset while he tells it.

How to deliver the punchline is of some debate. I would say, "Wow. I had a similar experience. (Insert story here.) I've never had that happen to me on a project that did Pair Programming, because someone else could always step in for me."

So said banshee858 <[email protected]> on 2/11/2003 --------------------
I have been having an interesting discussion with a colleague over 
the merits of XP and pair programming specifically.  My counterpart 
seems to more intent on winning the arguement than understanding what 
he came learn from these concepts and I have told him that was the 
impression I had.

However, he has a certain knee-jerk perceptions that I feel are quite 
prevalent among XP detractors and people who do not understand XP.  I 
eventually decided to give up on this conversiation, but I am curious 
to understand how other people have dealt with this resistence?  I am 
not really looking on how to "win", but to better understand 
what "we" are saying when we talk about these concepts.  

One complaint is pair programming is inefficent since you have less 
parallel task being worked on.  Three pairs can cannot not work on as 
many tasks in a single day as 6 programmers.  You "might" add value 
with pairing when two people of equal level are paired, but pairing 
should NOT be considered when two novices are together or people of 
unequal skill.  Asking an senior/expert developer to pair with 
someone lesser skilled only results in frustration for each person.  
It is assumed the junior person will not have anything to contribute 
since they are, by definition, junior.

Second complaint results from collective code ownership.  In this 
cas, knowledge is "too spread out" and you will get no "experts" in 
any one area.  Also, if somehow you became an expert, you could lose 
that knowledge as another pair "agressively refactored" the code you 
knew.

The only constraint I have is you cannot use "you have to try pair 
programming/XP to understand it."  Remember, we are trying to appeal 
to people who will NOT try it and they are CONVINCED they are right.  
So I am thinking we must try to convince them "on paper" before they 
are willing to take the risk of doing something different.  What sort 
of things have other said to appeal to the logical (or emotional) 
centers in these types of people?  Or will these people just not "get 
it", no matter what we say?  I seem to think they just don't "get it" 
and probably never will.


   


To unsubscribe from this group, send an email to:
[email protected]



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 
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.