Originally posted by Rick O'Shay:
I believe that if pair programming is effective quartet programming should be even more effective for the same reasons.
Originally posted by Rick O'Shay:
In fact pair programming is form of code review that is better handled in formal code reviews at the end of short iterations.
Originally posted by Rick O'Shay:
I have seen no crebible studies that show agile methods with pair programmign as delivering better product. I suspect none would because weekly peer reviews are superior.
Originally posted by Rick O'Shay:
I do agree that pair programming, or triplet or quadruplet programming, is an excellent means of mentoring but pair programming is not peer programming IMO.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
It's interesting that even advocates of pair programming admit that programming in pairs takes longer. So if one programmer could finish a website in 2 months, two programmers working together might finish it in two and a half months.Do you also believe that since 2 developers can finish developing a website in 2 months, 8 developers would finish the same website in 1 week?
IBM 286, SCJP, SCWCD, EIEIO
Originally posted by Ernest Friedman-Hill:
"Rick" --
You're apparently becoming a fixture around here, so it's high time someone pointed out our naming policy to you. It requires that you use a full, real first and last name for your display name, and joke names and "handles" don't cut it. You can change your display name here. We take this rule very seriously. Thanks for your cooperation.
Originally posted by Rick Portugal:
It's interesting that even advocates of pair programming admit that programming in pairs takes longer. So if one programmer could finish a website in 2 months, two programmers working together might finish it in two and a half months.
The benefit is supposed to be that they build a better site.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
MCP, MCP+I, MCSE(NT4), MCSE+I, MCSE(2000), MCDBA, MCSD(VS6)<br />SCJP 5.0, SCBCD 1.3<br />ICED(v5.0), ICSD (WSP5.0)
Originally posted by Tony William:
If we are already doing code review (between 2 developers), then how can one convince the management that pair programming can bring even more benifit to the project?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Rick O'Shay:
I believe that if pair programming is effective quartet programming should be even more effective for the same reasons.
In fact pair programming is form of code review that is better handled in formal code reviews at the end of short iterations.
I have seen no crebible studies that show agile methods with pair programmign as delivering better product.
I do agree that pair programming, or triplet or quadruplet programming, is an excellent means of mentoring but pair programming is not peer programming IMO.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jeanne Boyarsky:
When we pair, it doesn't take longer though. It doesn't take half the time either, which is what the advocates usually try to point out. So if the job takes one person 2 months to do, it may take a pair 5-6 weeks. Less calendar time, but more human/resources time.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Unless you also count the time that is spend on working through the bug reports that come from QA / the customer. If you do, PP tends to be much faster, in my experience.
Agreed. In my experience the biggest advantagde to Pair Programming is creating rock solid software.
Of course, you also have knowledge sharing and mentoring as well.
Pair Programming (like many other practices) is something you should try, experience, and use when appropriate.
Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
I appreciate that you have your opinion over the hypothesis. I just wanted to point out that the hypothesis -- increasing the number of developers collaborating in front of a single monitor would produce linear benefits -- was a bit ridiculous (which is why I asked if you also subscribe to that other ridiculous hypothesis).Originally posted by Rick O'Shay:
>> Do you also believe that since 2 developers can finish developing a website in 2 months, 8 developers would finish the same website in 1 week?
No, that was not implied in my opening post so let me clarify for you. If pair programming is better it implies a quartet is even bettern. You imply that a pair is optimal, nothing supports that. You imply that building out a site is the same as working on the same line of code simultaneously, you the analogy is bogus. Moreover, two more is not 200 nor 8. Finally, that was a hypothesis and personally I do not subscribe to it because pair programming is not better, IMO.
<br /> I agree that the studies are far from perfect with regard to their setup. Yet, it would be a small miracle if academic institutions would suddenly get corporate enterprises involved in developing the same software twice. Oh, and we'd still need to invent that memory reversion technique for making sure that the team cannot benefit from all the things they learned during the first time around.<br /> <br /> Then again, the same goes with just about everything in IT -- not just studying pair programming...<br /> <br /> In the end, if you want to see real proof on whether pair programming works, don't look for studies. Look for companies doing it. Ultimately, companies and their people are different so whatever a study says or another company does, it might not be portable to your own company. The only way to truly find out whether pair programming works for you is to give it an honest try.<br /> <br />Originally posted by Rick O'Shay:
>> Have you studied Prof. Laurie Williams' research? She's conducted empirical experiments with both academic and industrial focus groups and the results indicate that pair programming tends to lead to significant improvements in internal quality (and thus in overall productivity taking maintenance costs into account--something which is often left out of the discussions). <<<br /> <br /> Yes, pure garbage to sum it up. You remove pair programming, and only pair programming, and you have a statistically valid number of such studies and then perhaps you can draw a conclusion. That "study" had all the hallmarks of "I conclude X not give me a study that supports it". <br />
Originally posted by Rick O'Shay:<br /> >> Huh?
It's not that confusing, really. Pair programming as mentoring is effective.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Tony William:
If we are already doing code review (between 2 developers), then how can one convince the management that pair programming can bring even more benifit to the project?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Rick O'Shay:
I was pointing out that pairing up is clearly useful for mentoring but that taking two peers and putting them on one canvas with one person painting is counter-productive -- IMHO.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Rick O'Shay:
I was pointing out that pairing up is clearly useful for mentoring but that taking two peers and putting them on one canvas with one person painting is counter-productive -- IMHO.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jared Richardson:
Of course, you also have knowledge sharing and mentoring as well.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Barry Andrews:
I don't understand the reasoning behind proponent's of PP. Who is going to spot more problems in your code, someone looking over your shoulder or someone who is working on a separate project altogether or a different area of the same project? You have to do much more analysis if you don't know the area well.
The most successful ones? I don't get how did you come to that conclusion and how that relates to pair programming? (it's kind of obvious that pair programming is quite a bit more difficult if you've got one developer in Brazil and another in Sweden...)Originally posted by Barry Andrews:
Another case for no PP is open source projects? Open source projects are the most successful ones, and who has heard of using PP in an open source project?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Barry Andrews:
Who is going to spot more problems in your code, someone looking over your shoulder or someone who is working on a separate project altogether or a different area of the same project?
You have to do much more analysis if you don't know the area well.
Another case for no PP is open source projects? Open source projects are the most successful ones, and who has heard of using PP in an open source project?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
It would be interesting to know how you came to that opinion. Care to share your experience?
Interesting that you would come uo with the painting analogy: http://www.industriallogic.com/games/pairdraw.html
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Rick O'Shay:
I did pair up on several occassions and found it created a lot of drag.
OK, I'll buy that as worth investingating with a more prolonged test.
It's not that I am dismissing substantial anecdotal evidence in support of pairing but I believe the lion's share of that (opinion of course) can be traced to agile processes.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Rick O'Shay:
BTW, cool link:
http://www.industriallogic.com/games/pairdraw.html
I really just pulled the painting analogy out of the air since it struck me as analogous if not homologous. Not sure the results support pairing however!!!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Well, yes, you will certainly have to work harder to actually understand the code. I'm not sure how that translates to finding more problems.
Well, I have heard of that. JUnit was written that way, for example.
Anyway, nobody said that you can't successfully produce software without pair programming. So what
Consider Paul's rocket mass heater. |