Talk:Pair programming
From Wikipedia, the free encyclopedia
 |
It is requested that a photograph or photographs be included in this article to improve its quality. |
| The Free Image Search Tool (FIST) may be able to locate suitable images on Flickr and other web sites. |
The sentence in the intro describing the activity seems a bit weird ... "Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example." In my experience usually both programmers are working on the one task ... one is typing the code, and the other is helping to spot errors, for example. Maybe we should cite a source or two. Stumps 12:08, 22 May 2006 (UTC)
- Which sources do you have that says the they should do the same thing? People commenting on you drivings is not a help but people reading the map and tell you which way to go is a great help. --Equanimous2 17:45, 19 September 2006 (UTC)
- I agree. "One types in unit tests while the other thinks about the class..." is just wrong. The whole point of pair programming is continuous code review. I'll fix it right now. I don't have books handy, but I think finding citations will be easy. (A quick Google search turns up plenty.) --Ben Kovitz 21:45, 5 November 2007 (UTC)
Contents |
[edit] bad link
Pair Programming Productivity: Novice-novice vs. Expert-expert International Journal of Human Computer
... this link gives you a 404.
[edit] Utah study attribution
The Utah study quoted in the article gives attribution to Laurie Williams, but the coauthor of the study was Alistair Cockburn, one of the signatories to the Agile Manifesto -- hardly a disinterested party!
[edit] Survey on Distributed Pair Programming
Hello,
My name is Riad Djemili. I'm a computer science student at the Freie Universität Berlin in Germany. I'm working on a graduation thesis, which aims at examining distributed pair programming.
For this I've compiled a short questionnaire, which I would like to get as much as programmers as possible to answer. The survey is completely academic and has no commercial aims. This questionnaire is mainly aimed at programmers that have already worked with pair programming, ideally even distributed pair programming. It takes about 10 minutes to complete it. The URL is as following:
http://survey.mi.fu-berlin.de/dpp
Why should you take the questionnaire? You would help me in understanding in which ways distributed pair programming is currently used and therefore help me to research how distributed pair programming tools could be improved in general.
If you're interested in further information about the results of my work, you'll be able to leave your e-Mail after answering the questionnaire. Your e-mail won't be used for any other reason then this and will be deleted as soon as you've been contacted on the results of the survey.
This survey will be up until the 17st of July 2006. Please feel free to notify other potentially interested participants of this survey.
If you have any comments on this announcement, on the questions or on the topic in general, please don't hesitate to contact me at my e-mail address: djemili@inf.fu-berlin.de
Many thanks in advance, Riad Djemili
--88.73.114.251 12:04, 23 June 2006 (UTC)
[edit] n programming
Is triple programming, quad programming, etc. also in common? --Abdull 17:06, 27 July 2006 (UTC)
"Three programmers in front of one computer" is certainly less common than "two programmers in front of one computer". According to Wiki:TriProgramming and Wiki:PairProgrammingPlusPlus, triple programming (subjectively) seems to have both advantages and disadvantages compared to pair programming. As far as I can tell, no one has ever objectively compared triple programming to pair programming or single programming. Triple programming might turn out to be the best -- or the worst -- of those alternatives. --68.0.120.35 22:09, 10 April 2007 (UTC)
When working at Microsoft, I was handed a very hard to reproduce bug. I worked on it for 3 days, but although the problem did show up, the code seemed to be fine. I put several hundred breakpoints and watched almost every variable and still everything seemed to be right, the function was called only at the right times, but still the behavior of the whole program was incorrect.
The bug had something to do with UTF-8. At some place, ASCII was being used and the buffer would get garbage. The problem reduced to "who was using the wrong API?" in which the wrong AP woudl be strcpy and the right API would be utf8_strcpy, but the main problem was that strcpy was used literally millions of times in appropiate places, so finding the explicit line with problem was going to take too much time.
One morning I saw my boss with his boss and the test leader all looking at one screen in my boss's office. They all were debugging the code and looking for places where this could have happened, and then they realized the problem was in a little DLL we were using and which we didn't have the source code. It took a lot of time!!!
So, the 3-programming went on but they weren't programming, but were debugging at one screen. I think even though they weren't programming this is a valid example, because debugging at Microsoft usually takes too much time. The main reason is that they still don't discover UnitTesting
So much human power was needed because of the lack of abstraction. if all tyou do is to call strcpy, then you will have strcpy all over the place and eventually your program will be hard to change.
[edit] the drawbacks list
* Experienced developers may find it tedious to tutor a less experienced developer in a paired environment.
but isn't it more tedious to let that developer loose on her own and deal with the mess later? with pp-style tutoring, that developer may well become an experienced and talented developer in time
* A less experienced developer may feel intimidated pairing with a more experienced developer which may result in less participation. * Many engineers prefer to work alone, and may find the paired environment cumbersome.
isn't this sort of a circular argument, with "prefer" depending on some actual or percieved drawbacks?
* Productivity gains or losses are hard to compare between paired and non-paired environments, as metrics of programmer productivity are controversial at best.
weird phrasing, and is this really a drawback of pp?
* Experienced engineers quite likely produce code that is quite accurate, and the additional theoretical gain from pairing might not be worth the cost of an additional engineer. This is especially true when producing more trivial parts of the system.
dict "quite likely"
* Differences in coding style may result in conflict.
again, better to deal with this upfront than later.
* In the case where the team has slightly different work schedules, which is common in an environment that values work-life balance, the pair is only available during the overlap of their schedules. Therefore, not only does it require more man-hours to complete a task, a typical day has fewer pair-hours available, which further increases the overall task completion time. * Where a company values telecommuting (working from home) or when an employee must work from outside the office for whatever reasons, pair programming can be difficult and even impossible. However with broadband internet access and common screen sharing programs and VOIP technologies such as Skype, telecommuting can in fact better lend itself to pair programming. (see Remote pair programming) * Personality conflicts can result in one or both developers feeling awkward or uncomfortable. * Some developers can sit in front of a computer for many hours straight, others like to get up and walk around often.
that's fine; either take breaks often or just stand up and walk while the other person drives —Preceding unsigned comment added by 193.11.12.233 (talk) 12:15, 26 October 2007 (UTC)
[edit] Laurie Williams?
Did Laurie Williams write most of this article or sanction it? Most of the cites are quotes from her books and studies. And much of that is suspicious, such as "In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'" This is scientific? Sounds like it was probably a web survey of a pro-Pair Programming group.76.168.64.243 (talk) 19:33, 4 May 2008 (UTC)
- Nope, I put most of those references in. I believe Laurie Williams has been the leading researcher on pair programming. If you have more good sources, please add 'em! Ben Kovitz (talk) 08:36, 10 May 2008 (UTC)
