• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Quartet Programming

 
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 suspect none would because weekly peer reviews are superior. 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.
 
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pair programming, quartet programming, whatever. It's all a waste of time. Code reviews are the way to go, and if the code review happens to be in pairs then great. It's kind of like when you were in school and the teacher has you to trade papers with someone to grade them.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


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?

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.


Continuous code review is just part of pair programming...

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.


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).

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.


Huh?
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>> 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.

>> Continuous code review is just part of pair programming...

That's my point, sorry I didn't make it more clearly.

>> 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 /> <br /> >> Huh?

It's not that confusing, really. Pair programming as mentoring is effective.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Study

Take, say, 15 projects of a similar nature using agile processes without pair programming and 15 projects of a similar nature using agile processes with pair programming and discover what if any advantage pair programming provided.

I would like to see that study and whether it supports my observation that it results in a net-loss. What I believe is going on is that scrums and frequent reviews provide the peer pressure (a good thing in this case) and oversight the pair programming provides in a less flexible less productive way. Keep in mind, it's important to apply agile methods in both populations and that they be reasonable similar. Can two specific people develop code better and faster than one? Yes, about as many that can't so it's a statistical wash.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I should add, it's a statistical wash at best and in fact I propose that it's a net loss.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"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.
 
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?

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.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



I'm sorry if my acutal name is too whimsical for you but if you like I can use a fake name that sounds real, or perhaps Richard. I'll make sure Early doesn't sign up with her real name so that Mrs. Boyd isn't mocked.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Rick,
I agree that the overwhelming benefit is that the site is better with less bugs. And therefore less time trying to fix defects (which would have to be added to the 2 month figure.) Finishing isn't the largest cost in the long run.

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.
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
May I ask one question.

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?



Try it for a week or two. That's how a coworker and me did it. We already had some private experience with the technique, though.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Have you tried it? What did you experience?

I did, and I can tell you the following:

- Quartet programming was a great way of solving a conflict that the team (consisting of four developers) had. In that way, it was quite effective.

But it also becomes stale after a while (an hour or so), mostly because:

- there is only so much room around a monitor. With four developers around it, it gets nearly impossible to have everyone equitable. For example, those sitting less close to the keyboard are likely to collaborate less. This might work better with a projector instead of a monitor - in fact I know that some teams are doing this from time to time.

- communication in a quartet is much more complicated than in a pair. Most often you have someone who will feel unheard. That's much easier to notice and resolve in a pair...

- pair programming actually has two roles (which are switched between frequently) - the tactic thinking of the driver and the strategic thinking of the co-driver. Unless you find two more roles to fill, half of a quartet will likely feel redundant.

- one of the benefits of pair programming is that you need to communicate to your pair, which forces you to articulate your thoughts. It also ensures that the code communicates not only to yourself. Putting more developers into the mix is unlikely to improve things again at the same rate.

- You also benefit fromt he inspiration of the discussion with another person. Again, PMDITMIUTITAATSR.

- Working with a coworker tends to improve discipline - I'm much more likely to remember to write tests, to refactor etc. PMDITMIUTITAATSR

- Pair Programming also spreads knowledge in the team. PMDITMIUTITAATSR, especially if you switch partners frequently (such as several times a day).

All in my experience, of course - your mileage may vary.

In fact pair programming is form of code review that is better handled in formal code reviews at the end of short iterations.



Is it? Better in which ways?

I have seen no crebible studies that show agile methods with pair programmign as delivering better product.



Please show us the credible studies that show formal code reviews being better than pair programming. Thanks!

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.



Pair Programming is much more than that. I've no idea what you mean by peer programming - care to elaborate?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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.

But perhaps rally drivers would be much more effective if the codriver actually would drive his own car instead of just sitting next to the driver...
 
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rick,

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.

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).

Regarding the relative productivity of pairing over solo-development and having pairs of three, I can only testify that I have personally found pairing to provide benefits over solo development, and pairing with 3..n people occasionally being a good thing.

I wouldn't dare to claim that you should do the same as I do -- I would recommend trying it, though.

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 />

<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:<br /> >> Huh?

It's not that confusing, really. Pair programming as mentoring is effective.


I agree that it's effective as a mentoring technique. I just wasn't clear on what you meant by "but pair programming is not peer programming".
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?


Do you really need to convince the management? Why not just do it for a while and see if you get the benefits? If you do, you'll have something concrete to show your management. If you don't, well, then you probably don't feel the need to convince them anyway.

If there's a corporate mandate of not doing pair programming that's a whole another situation but (I hope) it's a rare case...
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Sounds like there is agreement on the time-to-market aspects but that quality is reported in increase. That's worth investigating.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To continue the neverending analogies we like so much...

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.


Yes, and the benefits of pair programming start to kick in when it's not anymore about just painting the canvas
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jared Richardson:
Of course, you also have knowledge sharing and mentoring as well.



Good point!

PP also significantly increases the Lottery Factor - the number of people you can loose to winning the lottery (and therefore leaving the project) without the project going down the tube...
 
Barry Andrews
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

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?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Pair programming--just like code reviews--are not only about finding defects. It's also about creating collective, intimate understanding of the system and codebase as a whole. One man coding and another one passively looking over the other's shoulder is not pair programming.

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?

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...)
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?



I seriously don't know. Have you tried both ways? What is your experience?

As an aside (and as Lasse already indicated), if PP feels to you like "someone looking over your shoulder", you are not doing it right.

You have to do much more analysis if you don't know the area well.



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.


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?



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?
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



I pair programmed for several days with my alter ego; but seriously, I did pair up on several occassions and found it created a lot of drag. People do seem to concur with that but they are claiming the output quality will rise. 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.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!!!
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Coincidentally, I was picking up the slack on my blogroll and noticed that Jeremy Miller has blogged quite a lot about pair programming lately:

Pairing for beginners (and skeptics)
Pairing rotation
Pairing is a great way to learn and teach
More on pairing
Pair programming ergonomics
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rick O'Shay:
I did pair up on several occassions and found it created a lot of drag.



Mhh, that's interesting - to me most often it's a lot of fun.

Can you explain what you think why it creates drag?

OK, I'll buy that as worth investingating with a more prolonged test.



When you do so, remember that PPing is a skill that needs to be learned like any other. Take a look at http://www.xprogramming.com/xpmag/Etudes.htm#N84

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.



So are you saying that pairing cannot work well in non-agile environments, or that the perceived benefits don't come from pairing but from other techniques - or something else?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!!!



Well, it's probably a matter of taste of which ones look better. The paired ones certainly look more *interesting* and *creative* to me, though.

Also keep in mind that a big part of the exercise is about how pairing *feels differently*.
 
Barry Andrews
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



In my opinion, you are going to be much more critical if you have to read code for the first time and understand it.


Well, I have heard of that. JUnit was written that way, for example.



Interesting. I did not know that.

Anyway, nobody said that you can't successfully produce software without pair programming. So what



Then what's all the fuss. It seems like it's the best thing since sliced bread.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic