programminginpairs.html

极限编程 Extream Programing

For some qualitative support of the effectiveness of <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>, see <a href="http://c2.com/cgi/wiki?AcmOnCollaborativeProgramming">AcmOnCollaborativeProgramming</a>.
<p>
<hr>
<p>
A variation on the theme of <a href="PairProgramming.html">PairProgramming</a> was noted in a Wall Street Journal article written by Scott Kilman, titled &quot;Monsanto CEO Races to Build Crop Biotech Power&quot;, (WSJ, p. A6, May 13,1998).  The article describes how Robert Shapiro, the chief executive officer of Monsanto Co., is rapidly changing the company through acquisitions, divestitures, and re-organizations.  
<p>
Kilman writes, &quot;Mr. Shapiro radically overhauled the old Monsanto management structure that grew up around the chemical business, creating co-executive positions for many of the top management jobs.  Technology and marketing managers are paired together and given equal authority over each other's areas of responsibility  - &quot;two in a box,&quot; he calls it.  &quot;Things are moving too fast for traditional management,&quot; he says.&quot;	- PeterMcHale<a href="http://c2.com/cgi/wiki?edit=PeterMcHale">?</a>		
<p>
<hr>
Anyone else tend to type &quot;Programming in Paris&quot;? (Must be wishful thinking.-)
<hr>
Another alternate we're trying out. We have a small team (three programmers), and don't feel that we can pair up all the time. Instead, we code in parallel, but have to explain the changes we've made to one of the other programmers before checking the code into source control. And if we do get stuck on a problem we feel is tricky, we do pair up. - <a href="http://c2.com/cgi/wiki?KatyMulvey">KatyMulvey</a>
<p>
Absolutely not the same thing. When successfully <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>, every hour the pair spends working together should result in significantly more than two staff hours of work. (At the <a href="ProgrammingInPairs.html">ProgrammingInPairs</a> BOF at OOPSLA 97, someone complained she didn't like it, because she was exhausted afterwards. I think that's actually a good sign! The good news is, you're a lot less tired than you would have been if you'd spent enough hours working by yourself to get the same amount of work done.)
<p>
It's possible to Program in Trios, but it takes an almost magic synergy. See the reference to &quot;wedding&quot; above. &quot;Writing in Pairs&quot; is less magic, so often one of us would write while the other two programmed.
<p>
When holding a group <a href="http://c2.com/cgi/wiki?CodeReview">CodeReview</a>, there's often the presence of an InvisibleReviewer<a href="http://c2.com/cgi/wiki?edit=InvisibleReviewer">?</a>, because more happens in the group than any of the individuals could have done at our desks. That's even more true of <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>.
<p>
Katy, I think you are getting one benefit of <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>, namely, having shared knowledge of what the code does. (<a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a> belongs to the trio.) But you're missing so much more!  --<a href="http://c2.com/cgi/wiki?PaulChisholm">PaulChisholm</a>
<hr>
In many situations, the paired programmer need not be programming literate, but problem domain literate. Having the domain expert sitting alongside, the programmer can question the expert immediately regarding something that comes up but isn't apparent until the code itself is being written. To answer several &quot;what if&quot; situations. As a corallary, the expert can have the programmer explain what is being done, and comment on whether the programmer is going down the correct path or has perhaps made a wrong assumption.
<p>
This closeness can help clarify muddy parts of a spec, and burn through the intentions of the problem. It tends to speed the entire process up.
<hr>
What programming, especially in pairs, feels like, at least in one case:
<p>
<a href="http://www.salonmagazine.com/21st/feature/1997/10/cov_09ullman.html">http://www.salonmagazine.com/21st/feature/1997/10/cov_09ullman.html</a>
<p>
<em>Yuck.  I read the article with growing horror.  Just another example of pseudo-heroic sloppy cowboy debugging.  <a href="ProgrammingInPairs.html">ProgrammingInPairs</a> appears to give back more than it takes - the opposite of what the article illustrates.  Having not done <a href="ProgrammingInPairs.html">ProgrammingInPairs</a> (yet!) I can't speak from experience, but I know someone could...</em> -- <a href="http://c2.com/cgi/wiki?RodneyRyan">RodneyRyan</a>
<p>
It's a weird book (<a href="http://c2.com/cgi/wiki?CloseToTheMachine">CloseToTheMachine</a>). She has a very strange, dark outlook. But much of what she writes expresses a truth that many have lived.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<em>I agree.  However, I'm asking if people who have practiced <a href="ProgrammingInPairs.html">ProgrammingInPairs</a> view the article as a good example of <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>.  Is it a situation that indicates movement in the most effective direction ?</em> -- <a href="http://c2.com/cgi/wiki?RodneyRyan">RodneyRyan</a>
<p>
Ullman got the mind-meld part right. And she understood that pairs didn't have to be equals to be effective. But she couldn't keep the meld up through completion with the first developer and couldn't even start to meld with the second. Amateurs. -- <a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a>
<p>
If you took out all the macho midnight brainburn stuff, the experience isn't atypical. Done calmly and peacefully, however, it's more a gentle flow than this orgasmochistic explosion of sensation.
<p>
<hr>
<p>
This is good stuff, but I'm wondering about two issues (which may be discussed elsewhere, but I haven't found them).  The first is, how does the <em>pairing</em> process work, what happens if two people consider themselves incompatible?  It
strikes me that if the individual developers are entirely self-organizing it could produce negative effects.
Also, is there a bun-fight over particular <em>interesting</em> tasks?  I can imagine
in a well-factored system there mightn't be a big variance between appealing and
dull tasks, but with a large legacy system there is bound to be.
--<a href="http://c2.com/cgi/wiki?EoinCavanagh">EoinCavanagh</a>
<p>
In XP, team members sign up for tasks. Tasks are never assigned. Some days there's a rush to sign up for some particular thing, but I've never seen it come to blows. Since XP developers are completely cross-trained, they're generally ready to sign up for anything and the signup process is stress-free. Once in a while I might &quot;encourage&quot; someone to sign up for a specific area, or more rarely discourage.
<p>
I've met one developer with whom no one could pair. He seemed to be an anomaly. Within C3, all the teams work pretty well. Once in a while I have to whack someone with the rolled-up newspaper to get them to behave. Folks develop favorite partners, and we just quietly encourage them to shop around. We've seen no negative effects. --<a href="RonJeffries.html">RonJeffries</a>
<p>
<hr>
I'm a graduate student at the University of Utah -- doing my dissertation about this pair programming stuff.  I'd LOVE to get some information about how it feels to pair program, what works, what doesn't work, etc.  So, I've developed a questionnaire.  It would be great if anyone out there who has pair programmed could take a few minutes and fill out my questionnaire.  It should take between 3-5 minutes, and would GREATLY help my research.  On the questionnaire, there's a link to my dissertation proposal, in case you are interested.
<p>
<a href="http://limes.cs.utah.edu/questionnaire/pairprogramming.asp">http://limes.cs.utah.edu/questionnaire/pairprogramming.asp</a>
<p>
Thanks a ton!  -- <a href="http://c2.com/cgi/wiki?LaurieWilliams">LaurieWilliams</a> 
<p>
<hr>
Results of the survey (above) are now posted at <a href="http://limes.cs.utah.edu/questionnaire/questionnaire.htm">http://limes.cs.utah.edu/questionnaire/questionnaire.htm</a>
Feel free to answer the survey if you haven't yet!  Thanks for participating.
<p>
-- <a href="http://c2.com/cgi/wiki?LaurieWilliams">LaurieWilliams</a>
<hr>
A logistical question:  I hear that it's not uncommon for people to switch pairs several times a day.  How is that done?  For example, if someone needs to work with me for a while, what does my old partner do?  Pair with the old partner of the person I'm now paired with?  Find someone else?  Work alone on something?  Or suppose my pair needs to go grab someone to work with.  I've noticed in practice that ProgrammingInTrios<a href="http://c2.com/cgi/wiki?edit=ProgrammingInTrios">?</a> doesn't work too well, two of the people tend to focus on each other leading to a &quot;third wheel&quot; effect.  So if my pair grabs someone to consult, should one of us in my pair go do something else or find a new partner?
<p>
Also, do pair programmers ever feel tempted to &quot;cave&quot; on something when it's causing a lot of friction with their partner?  I noticed that when I was experimenting and had to guard against it, and was wondering if it's a common problem in practice.
<p>
-- <a href="http://c2.com/cgi/wiki?NathanUrban">NathanUrban</a>
<hr>
This is an interesting discussion, after reading a bit out this <a href="PairProgramming.html">PairProgramming</a>, I have to admit that I myself have done some with a partner somewhere in the states... I am one of those programmers who loves to write code, but is always switching track, and never getting anything finished (at least to initial distribution)... I found that a lot of work did get done, and that it was much easier to focus on the task at hand while working with another person. 
<p>
What we ended up doing, was setting up a CVS server that we could work from, and since we had never met each other and most likely never would, communication was very important. We tended to write a lot of comments into the code because we couldn't speak to one another on the spot... &quot;I changed this because...&quot; or &quot;I had to add this bit to do that...&quot; what tended to happen was that one of us would write a bit of the applcation, and another would come along and streamline it and in some instances even replace the model with a better model, or one that was more in-line with the style we where working in...
This meant that not only was code getting written, but we where forced to understand and think about what we where doing, and what we wanted to accomplish.
<p>
The biggest problem was that when our server went down for reasons out of our contol, the project stopped... by the time the server was back up both of us had found other projects to occupy our selves with...  In other words the pair model worked well while we could apply ourselves to it, but the moment we where interuppted for any length of time, it was very difficult to get back in sync, and get the steam back up.
<p>
We never did get back to the project... but you can see a screen shot at: <a href="http://www.jmonkey.com/products/lexi/index.html">http://www.jmonkey.com/products/lexi/index.html</a>
<p>
-- <a href="http://c2.com/cgi/wiki?BrillPappin">BrillPappin</a> 
<a href="http://www.jmonkey.com">http://www.jmonkey.com</a>
<p>
<em>Brill, what you describe is not <a href="PairProgramming.html">PairProgramming</a>. It is geographically distributed collaboration. <a href="PairProgramming.html">PairProgramming</a> means: two programmers are sitting at the same computer at the same time, working on the same problem.</em>
<hr>
How do you avoid the situation of the more dominant member of the pair taking over and the other sitting watching and not contributing? -- <a href="http://c2.com/cgi/wiki?IanCunningham">IanCunningham</a>
<p>
<em>See <a href="http://c2.com/cgi/wiki?SurprisingReverse">SurprisingReverse</a> for one answer.</em>
<hr>
<p>
There must be similar advantages and disadvantages to <a href="http://c2.com/cgi/wiki?WritingInPairs">WritingInPairs</a> and <a href="PairProgramming.html">PairProgramming</a>.  Many people ask for help composing an important email or difficult paragraph.  There are also similarities between DocumentEditing<a href="http://c2.com/cgi/wiki?edit=DocumentEditing">?</a> and a <a href="http://c2.com/cgi/wiki?CodeReview">CodeReview</a>.  Both often use printouts and occur away from a computer.  However, the first is usually done alone (usually with a red pen on paper) and the second is done in groups.  I suppose reviewing code can involve many people without wasting everybody's time because code is much more prone to be buggy and/or need explanation.  Any explanation, of a fix, of the architecture, of a <a href="http://c2.com/cgi/wiki?DesignPattern">DesignPattern</a>, is likely to improve the skills of all members of the code review.  -- <a href="http://c2.com/cgi/wiki?LisaDusseault">LisaDusseault</a>
<p>
<hr>
<a href="http://c2.com/cgi/wiki?CategoryPairProgramming">CategoryPairProgramming</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=ProgrammingInPairs">EditText</a> of this page (last edited March 13, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=ProgrammingInPairs">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>