This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes Quartet Programming Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Quartet Programming" Watch "Quartet Programming" New topic
Author

Quartet Programming

Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
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.
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

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.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> 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

Joined: Sep 19, 2004
Posts: 531
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

Joined: Sep 19, 2004
Posts: 531
I should add, it's a statistical wash at best and in fact I propose that it's a net loss.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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


[Jess in Action][AskingGoodQuestions]
Rick Portugal
Ranch Hand

Joined: Dec 17, 2002
Posts: 243
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.


IBM 286, SCJP, SCWCD, EIEIO
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
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.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30403
    
150

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Tony William
Ranch Hand

Joined: Jun 27, 2005
Posts: 54
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?


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)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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...
Jared Richardson
author
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
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>
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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

Joined: Sep 19, 2004
Posts: 531
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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Sep 05, 2000
Posts: 523

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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Sep 19, 2004
Posts: 531
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

Joined: Sep 19, 2004
Posts: 531
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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Sep 05, 2000
Posts: 523

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Quartet Programming