Talk:Pair programming
Software: Computing C‑class High‑importance | |||||||||||||
|
Guild of Copy Editors | ||||
|
Complaint about intro
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)
bad link
Pair Programming Productivity: Novice-novice vs. Expert-expert International Journal of Human Computer
... this link gives you a 404.
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!
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)
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.
Cool story bro'. What the fuck does it have to do with anything?
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)
- Chat sessions: Sometimes employees might talk together too much, straying excessively into off-topic subjects, such as major news events, personal problems, etc.
- Annoying personal habits: Sometimes people can find each other much more annoying when working up close than at separate workstations.
- The current version has a couple inconsistencies. The first few are solid, cost-effect-possible-issues discussion, and the last two, posted above, are not well structured. I think it'll be good to drop the last one and change the chat sessions one to the following:
- Added Distractions: Employees might be more inclined to stray off-topic and discuss issues not pertaining to the project or workplace for extensive periods, wasting valuable time. 64.236.128.12 (talk) 15:28, 17 July 2008 (UTC)
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)
- How about extracting the quotes into a Notes section, using shortened footnotes (Citing Sources style guide)? The Williams quotes are well researched, but currently, the other references are somewhat drowned out.
- I just changed the references to a 2-column format. Does that help? I couldn't figure out how to do shortened footnotes and still keep all the quotations intact. I'd like to keep the quotations so it's easy for readers to quickly check the substance of the reference and make objections like the one above. --Ben Kovitz (talk) 04:07, 18 February 2009 (UTC)
All of the actual scientific, peer-reviewed studies I've read on pair programming have found no benefit to experienced programmers, only to students. This article is very heavily biased based on programmers self-reported _impressions_ and _feelings_ regarding the benefits, instead of the actual lines of code and quality of the code produced. Of course pair programming makes most programmers feel better about coding- coding is, like writing in general, a lonely, cognitively-rich task, and pairing makes it much less lonely- but that doesn't mean that it makes the output better. 173.228.123.235 (talk) 11:09, 6 November 2011 (UTC)
Extract Remote pair programming into separate article?
How about extracting Remote pair programming into a separate article? The External links and References are somewhat cluttered now, particularly the list of tools for remote pair programming. —Preceding unsigned comment added by 85.166.140.106 (talk) 20:11, 21 July 2008 (UTC)
External links in See Also section
Some external links seem to have worked their way into the See Also section. I'm not really sure how they got away with it as I don't actually see any URLs in the raw text. I'm not sure how this should be dealt with, but at least I've brought it up. Isarl (talk) 02:35, 10 October 2009 (UTC)
Additional drawback
* Programmers can engage in over-analysis
I can't back this up with a research link, but I'm sure you'll agree that this is a common problem with pairing, especially with verbose types who need to make their opinion heard. I've had whole pair programming sessions wasted with stupid conversations. You can say it can be avoided, but introducing a social aspect to programming does have this inherent drawback of unnecessary conversation. Erichero (talk) 08:28, 22 December 2009 (UTC)
- Sounds like original research. There have been a lot more studies of pair programing in the last few years. If you can find one that describes this, by all means, put it in. If you can find studies that measure the effect on time to completion, that would be especially good, since that's the bottom line of interest. —Ben Kovitz (talk) 03:16, 14 June 2010 (UTC)
- The entire drawbacks section appears to be missing... — Preceding unsigned comment added by 205.221.255.62 (talk) 16:28, 14 January 2014 (UTC)
Phasing out "Scientific studies" section
I'm now phasing out the section listing scientific studies, and moving the quantitative results and references to the "Costs and benefits" section. There are still some duplicate studies, because I don't want to lose the quantitative information and references, and I haven't gotten access to all the references. In particular, I'm hoping to see the "Costs and benefits" section summarize the findings regarding defect rates, time to completion, and total effort. That will make the article very useful to readers interested in what is known about pair programming. If anyone else would like to help gather up this info and put it into "Costs and benefits", please don't be bashful! —Ben Kovitz (talk) 03:25, 14 June 2010 (UTC)
What does effort mean in all this?
Not being a researcher in this field, or a programmer, I have no idea what effort means when it comes to programming? Pay? Physical effort? Mental effort? — Preceding unsigned comment added by TheThomas (talk • contribs) 11:55, 11 December 2010 (UTC)
- Excellent question. As defined in the paper by Arisholm, et al., effort is total programmer-hours. I'll add that to the article right now. —Ben Kovitz (talk) 19:23, 16 March 2011 (UTC)
"The fusing of pair and solo programming"
Snipped the following section:
- The role of pair programming in software development is controversial. This is due partly to the relatively unclear benefit of pair programming over solo programming. There have been arguments either way and there have been studies to show that one is more cost-effective than the others. Rather than investigating into pair vs. solo programming here, a new process model was created which combined both together. The fusing of pair and solo programming processes may actually be better than adopting either alone. In the proposed model, a donor and a recipient process can be defined and if some transfer conditions are met, one process can be converted into another to achieve tasks with minimal costs. The fusing of pair and solo programming can be a more effective approach to increase productivity of less experienced programmers.[1]
After reading it, I'm skeptical that it belongs in Wikipedia at all; it reads more like a new proposal than a description of something that exists. I haven't read the source, but I'm guessing it's a scholarly argument in favor of the technique rather than a description of something already in use. I could see mention of this being appropriate in the article if it were described as an untested idea that someone had rather than a proposition being made by Wikipedia. --Brilliand (talk) 19:13, 28 February 2011 (UTC)
Marketing Spin or Technical Accuracy?
What is the purpose of the article? Content sounds too subjective. The most specific, technically accurate definition is "two people working together, at a single terminal". In the 1980s this was called "working together" and was typically limited to academia. Kernel.package (talk) 13:56, 15 March 2011 (UTC)
- It's more specific than that. The main idea is continuous (line-by-line) code review. Of course, many other things happen in addition to code review when one person sits and watches the person whose code they're reviewing. If you're interested, please read the article and look into some sources, and you may find a way to make the article more informative. —Ben Kovitz (talk) 19:08, 16 March 2011 (UTC)
Please help explain
I am a Wikipedian and contribute to zh.wp, I am translating the article to Chinese, but I cannot understand the "The benefit is strongest on tasks that are not yet understood by the programmers, calling for more creativity, challenge, and sophistication", I am not sure which meaning of sophistication should use. Thanks in advance. --Yongxinge(talk) 13:22, 23 March 2011 (UTC)
- Hi, Yongxinge. I tried rewriting the sentence to be clearer, but I'll try explaining more here. (Maybe someone else can improve the English version, too.) The idea is that pairing does the most good, in comparison to each programmer working solo, when the problem to be solved is difficult because it's not fully understood by the programmers when they start. By pairing, they spur each other's creativity and help define the problem better. Working solo, a programmer typically has a harder time understanding the problem, works for longer, and doesn't come up with as appropriate a solution. By contrast, pairing is less beneficial, in comparison to working solo, on routine problems that are already familiar to the programmers. For example, changing all occurrences of a certain string literal in a program is not a likely task where pairing will do much good. But figuring out a deep bug that no one understands yet is likely to go much better with pairing. (In fact, people often "pair" on debugging without ever having heard of pairing, since the difficulty of the problem clearly calls for two people to work together. The interesting idea of pairing as described in the article is that it can help even when writing new code, although then it requires a little more discipline.) Does that help? —Ben Kovitz (talk) 04:20, 19 April 2011 (UTC)
Separate workstations?
Yujunliang has posted a pic in this version with the caption, "While hardware becoming relatively cheap these days, a new setup with two monitors sharing one workstation became more popular in the industry." Is this true? Are there sources that establish this? My understanding of pair programming is that: (a) the expense of hardware was never a concern, even in the earliest days: usually each programmer had a separate workstation, anyway, but when pairing, they worked at just one workstation; (b) pairing loses a lot of its effectiveness when both programmers are not looking at the same screen or when both programmers have access to keyboards (because the programmers stop reviewing each other's work and stop explaining out loud what they're doing). That's mostly from personal experience, although the sources I've seen nearly always speak of two programmers at one workstation, and the cost of programmer time has always been seen as the leading drawback of pairing, not the cost of the workstations. Has there been a big change? —Ben Kovitz (talk) 04:04, 19 April 2011 (UTC)
Hi Ben,
To answer your question, this picture was taken in the office of my client, a financial company in Dallas. Please look closer, the two monitors display the same content. They are connected to the same workstation via signal splitter. This setup solved the problem of making two developers staying too close to each other. I can provide more detail about the setup if you are interested. Sorry for the confusion earlier. — Preceding unsigned comment added by Yujunliang (talk • contribs) 00:54, 20 April 2011 (UTC)
- Thanks for telling me how you got the picture, Yunjunliang. It sounds like your client is doing an interesting experiment. Is it original research, though? Is pairing with separate keyboards and monitors typical in industry now, or is it something unusual? If it has become typical (contrary to the sources now used for the article, which are several years old), are the any sources to verify this? —Ben Kovitz (talk) 16:51, 20 April 2011 (UTC)
This is the normal setup from the company I work for, ThoughtWorks Inc. But we are not alone, please see the setup in this blog entry, http://devblog.point2.com/tag/intellij/
- Sorry to take so long to get back to this thread! Unfortunately, it sounds like the picture does not do a good job representing common practice. Doing this at one or two companies doesn't make it the ordinary practice, and a blog post without editorial oversight is not a reliable source. The pic is of poor quality: the composition is poor, and it doesn't clearly illustrate pair programming or even the specific variant of pair programming that you've described. An improved pic of the same thing wouldn't help, because of all the other problems I noted above, which you didn't address. So, I'm deleting the picture. Please don't add it back. —Ben Kovitz (talk) 01:33, 7 August 2011 (UTC)
IEEE Citations only available to IEEE members
[1] an IEEE citation is only available to IEEE members. It is unlikely anyone outside of IEEE members will be able to read this. A freely available Internet citation is needed. Johnswolter (talk) 14:02, 12 September 2011 (UTC)
- Free preprints are useful, but not required see WP:PAYWALL. Tijfo098 (talk) 21:03, 18 November 2012 (UTC)
reference doesn't support Ping Pong Pair Programming claim
The reference to http://www.c2.com/cgi/wiki?PairProgrammingPingPongPattern does not support or deny the claim that "In general, this approach may take more time than the estimated plan." Seems like the reference should be nixed. — Preceding unsigned comment added by 76.191.142.169 (talk) 14:23, 28 October 2011 (UTC)
- Done. —Ben Kovitz (talk) 14:12, 26 May 2012 (UTC)
There seems to be an error
Pairs usually complete work faster than one programmer assigned to the same task.
&
Even though coding is often completed faster than when one programmer works alone, total programmer time (number of programmers × time spent) increases.
Are contradictory, one claims pairs are faster and the other claims solo is faster, I believe the intention in the second sentence was:
Even though coding is often completed faster than when two programmers work together, total programmer time (number of programmers × time spent) increases.
as this also seems to make more sense, due to the first version being redundant and, well wrong, I don't really know how to explain.
193.105.7.54 (talk)
- I don't think the two sentences contradict each other, and both are correct, but the distinction is a little subtle: less calendar time, but more total programmer-hours. Someone else brought up the same confusion in the section "What does effort mean in all this?", above. You are more than welcome to clarify and improve the wording. —Ben Kovitz (talk) 14:24, 26 May 2012 (UTC)
Miscellaneous questions
Anybody with a miscellaneous question, please place it here.
What is the prevalence of pair programming? I mean, how much is it used?CountMacula (talk) 18:52, 3 September 2012 (UTC)
No costs
Why are there no costs listed in the "Costs and Benefits" section in the introduction? The section implies there is not a single drawback, as everything here is positive. — Preceding unsigned comment added by 137.71.23.54 (talk) 16:20, 26 November 2012 (UTC)
Neutrality
I've added the neutrality template to this article. It only includes advantages to this development method while the language reads almost like a sales pitch in some areas. Furthermore, the first 13 sources (more than half of the total) were written by the same author, most of which in the same publication. It looks as though the references count has been artificially inflated by counting each page of the same references as a separate reference entirely.
Concern was also raised here by another user about the fact that the "Costs and Benefits" section only contains benefits. That concern has never been addressed or even discussed since it was raised three months ago.
Because of the extremely poor quality of the article's citations and rather blatantly biased perspective, I've decided to add a couple other relevant templates as well. Please do not remove them until the issues raised here have been resolved. Some parts of the article may need to be rewritten so that they're not relying almost exclusively on a single source. KrisCraig (talk) 03:23, 1 February 2013 (UTC)
Replication (not in cited article)
An Article by Giri and Soni is being cited as a reference for experimental replication that pair programming is effective. This article does not provide such evidence.
Some quotes from an article being cited as evidence for replication: "This experiment was carried out on students for learning purposes; therefore the experiment was not strictly monitored." and in the Conclusion: "The primary contribution of this study is to provide an overview of Pair Programming and to demonstrate the use of Programming Aptitude Test in the aspect of pair generation or team building that facilitates to make pair of newly hired programmers in an industry." Derek farn (talk) 12:10, 26 November 2013 (UTC)
In the section 2, the authors replicated the horse-trading system on their own in the background section, and the authors achieve the same results as quoted previously. — Preceding unsigned comment added by Hzhbcl (talk • contribs) 12:20, 26 November 2013 (UTC)
- Hzhbcl, To regard this work as a viable replication is clutching at straws. The authors of the paper don't claim that it is a valid replication and explicitly point out it was done for learning purposes and not monitored. Why are you so desperately for this to be a replication? Derek farn (talk) 15:32, 26 November 2013 (UTC)
Impersonal and dehumanizing
Is there going to be any mention of how impersonal and dehumanizing p.p. can be? Any two random people in the West are likely to have vastly different work habits, and prolonged p.p. is going to make them hate each other. It goes against the grain of individual independence and freedom. Ever see two painters painting the same canvas? Two cooks making the same soup? Two equal drivers in a car? No, no, and no. I urge managers worldwide to stay away from or at least never enforce this hideous methodology. Collaboration and feedback are undoubtedly essential, but p.p. takes it to the extreme, and the extreme is always a dangerous place to be. When I'm programming, I like to be lost in my thoughts, think a problem through, feel that light bulb turn on, explore and experiment, and not be yapping with anybody else. Unless my pair is a 10/10 fine 6ft blonde, in which case I'll also be exploring and experimenting with her, I would rather be left to pair with myself. Remember, programmers are typically much more introverted than extroverted. --IO Device (talk) 23:48, 3 January 2014 (UTC)
Nit: Plural of "code" is not "codes"
Tiny nit. The plural of "code" is not "codes" in this situation.
Thomaso (talk) 15:33, 18 February 2014 (UTC)
Correlation is not causality
In the Benefits section, it states "A correlation exists between satisfaction among programmers and their confidence in the codes i.e. the pairs enjoy their work more because they are more confident in it.". I do not have access to the referenced paper, but based on the text at hand, this is an invalid conclusion. Correlation between two things does not necessarily mean that one was caused by the other. (It would perhaps be correct to change this to "it may be that the pairs enjoy their work more because they are more confident in it.") -- Foogod (talk) 20:53, 10 March 2014 (UTC)
- ^ [Software, IET|http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4595506&tag=1]