aspose file tools*
The moose likes Agile and Other Processes and the fly likes blog of Kathy - Pair Programming is NOT always a choice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "blog of Kathy - Pair Programming is NOT always a choice" Watch "blog of Kathy - Pair Programming is NOT always a choice" New topic
Author

blog of Kathy - Pair Programming is NOT always a choice

Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Phew! I am not alone, I mean I am not the only one who is alone !! What a relief

http://weblogs.java.net/blog/kathysierra/archive/2004/03/pair_programmin.html

[ thread title changed because it interfered with winner picker -ds ]
[ October 09, 2004: Message edited by: Dirk Schreckmann ]

The future is here. It's just not evenly distributed yet. - William Gibson
Consultant @ Xebia. Sonny Gill Tweets
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Sonny, can you tell us more about your experience with PP, please?


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
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Ilja,

I was actually referring to being a bit of a loner in general, and not specifically in relation to Pair Programming. I also find that, although I am perfectly ease at being in company of other people, often I prefer not to. For me, staying at home reading a good book, or getting together with one or two friends at a quiet place is as much fun ( if not more), as going out and meeting with a large group of people. And I find it really strange when some people think that there is something wrong with that.

Now from my limited knowledge of PP, although pair programming is not a standard practice at my work place, I find that I am really uncomfortable working if there is somebody sitting right beside me looking at it all the time.

But, I have no problem going through any code that I have written with someone trying to find problems or explaining it etc. And that piece of code can be as small as a 10-20 lines long method, but while I am writing I prefer to be alone.

So, I am fine with a practice where, for example, I spend 30 minutes writing some code, and then I spend 10 minutes with someone going through it, and then back to coding on my own.

cheers mate.
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

TWO programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work.


http://www.pairprogramming.com/

This doesnt quite look like something for me

At my work place though, I sit right accross from my colleague, and we talk to each other to discuss any problems or solutions, occasionally he will roll his chair next to mine to work on something together (and vice versa), and then back to our desks again.
Often if he needs me to look at something, he will do a quick commit, I update my copy, and we go through the code togehter while we stay where we are.
Linda Rising
Author
Ranch Hand

Joined: Jan 21, 2001
Posts: 76
There are so many principles of XP or the other Agile Methods whose goal it is to get us to work well together. PP is probably at the top of that list. I'm not sure it's necessary to adopt this practice if it doesn't work well for you *and* if you communicate with your team members and do some kind of code review. Yes, it's probably better if you can do PP, but there's plenty of research to show that introverts (and most developers are introverts) are most comfortable working alone. It requires extra energy to interact with others. Extroverts, on the other hand, find that their energy is increased by being around others. We are individuals, after all, and have our own best working styles.


Linda Rising<br />Author of <a href="http://www.awprofessional.com/title/0201741571" target="_blank" rel="nofollow">Fearless Change</a>
U Patel
Greenhorn

Joined: Sep 28, 2004
Posts: 18
Originally posted by Sonny Gill:


At my work place though, I sit right accross from my colleague, and we talk to each other to discuss any problems or solutions, occasionally he will roll his chair next to mine to work on something together (and vice versa), and then back to our desks again.
Often if he needs me to look at something, he will do a quick commit, I update my copy, and we go through the code togehter while we stay where we are.

Isn't this call peer review!!! Which is a very good prectice. Produces less bugs and a very good over all design for piece of work is getting done. Given a scenario that we have a very good design in place, I never liked the idea of one person is coding and another is driving. To me, it would be like having a navigation system for a route I have drove on about 5 million times. Or like I have a second driver next to me constantly giving out running commentary. Just irritating!!!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sonny Gill:
I was actually referring to being a bit of a loner in general, and not specifically in relation to Pair Programming. I also find that, although I am perfectly ease at being in company of other people, often I prefer not to. For me, staying at home reading a good book, or getting together with one or two friends at a quiet place is as much fun ( if not more), as going out and meeting with a large group of people. And I find it really strange when some people think that there is something wrong with that.


Oh, me too!


Now from my limited knowledge of PP, although pair programming is not a standard practice at my work place, I find that I am really uncomfortable working if there is somebody sitting right beside me looking at it all the time.


Interestingly, I enjoy PP quite a lot. I wouldn't want to do it 100% of the time, but wouldn't object to 80%.

It took me some time to learn this skill, though. Most importantly, I don't any longer like someone is observing me while I code, but like we are coding together.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Linda Rising:
there's plenty of research to show that introverts (and most developers are introverts) are most comfortable working alone.


Do you have any references?

I'm quite sceptic, because I have seen an extreme introvert becoming a PP fan in my team.

When I joined the team three years ago, he would typically get his assignment, look at a blank wall for 3 hours, and then code the solution. Getting him to even notice you while he concentrated required a whole lot of effort. We PP'ed a little bit to get me up to speed, but it certainly wasn't easy and didn't stick as a practice.

Today, he is of course still an introvert, but he also prefers to PP. It's still sometimes a little bit of a strange experience, for example if you, as his PP partner, ask him a question and he doesn't react to it for minutes, staring at the monitor. But we, as a team, have learned to accept and live with that.

It requires extra energy to interact with others. Extroverts, on the other hand, find that their energy is increased by being around others. We are individuals, after all, and have our own best working styles.


I don't know anyone, though, who doesn't think that PP'ing for 7 hours is exhausting, though - wether introvert or not.

And what's even more important, *learning* PP requires effort, too. You can't expect your first weak of PP'ing to be smooth and trouble-free.

In my opinion, it's a skill worth learning, though.
[ October 04, 2004: Message edited by: Ilja Preuss ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sonny Gill:
http://www.pairprogramming.com/

This doesnt quite look like something for me


What specifically looks like it isn't for you?

Would some of the things mentioned at http://xprogramming.com/xpmag/Etudes.htm#N84 make it more comfortable to you?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by U Patel:
Isn't this call peer review!!! Which is a very good prectice. Produces less bugs and a very good over all design for piece of work is getting done.


The main advantage of PP over conventional peer review is that suggestions for improvement come while the code is written, not after it is finished. That has several consequences:

- it's much easier to accept a suggestion from someone working with me on *our* code, than from someone nitpicking on *my* code that I supposed to be finished;
- it's much less effort to incorporate improvements into the code while it's currently being formed than when it's already finished;
- when we discuss the code while we write it, we get much faster feedback on what the result of the improvement looks like, and therefore can discuss wether it really was an improvement and/or wether we now see even more ways to improve it.


Given a scenario that we have a very good design in place, I never liked the idea of one person is coding and another is driving. To me, it would be like having a navigation system for a route I have drove on about 5 million times. Or like I have a second driver next to me constantly giving out running commentary.


Well, that's actually what rally teams prefer to do.

I actually have never seen - and can't imagine - a design that I don't learn something about while coding it.

And if I really felt like coding something the 5 millinon'th time, I'd wonder wether I'm missing some opportunity for reuse. But perhaps I'm just not understanding what you wanted to express using that analogy...
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
I much prefer working alone and I have to admit to a few different reactions here:

Kathy likens forcing loners to pair program as being like forcing non-loners to be alone: "They become stressed, depressed, anxious".

To which I have to respond, nothing guarantees that your job won't be stressful. Few get to do something they truly enjoy and make money at the same time. If a loner doesn't want a job that's overly stressful, they probably shouldn't take a job as an XP programmer, any more than they should take a job as a telemarketer.

Despite loners being in the minority in the overall population, I think most good programmers used to be loners, because non-loners didn't do well in the job: they got bored and inattentive when alone, and so didn't do a good job during long hours of programming or debugging. Pair programming in XP is largely a way to allow non-loners to be productive programmers as well, especially as enough software people are now required that there aren't enough loners to fill the ranks. Unfortunately, pair programming does this in a way that doesn't really work well for mixed teams of loners and non-loners.
[ October 04, 2004: Message edited by: Warren Dew ]
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211


I'm quite sceptic, because I have seen an extreme introvert becoming a PP fan in my team.


That is interesting. May be I will take a shot at PP too.
Do you find that for PP to work, esp. for introverts, the person they pair with has to be 'just right' for them? Perhaps similar skill level, and who knows when to interrupt and when not. Two people pairing up to program must both have something to offer to each other. If there is a big gap in skills, for example, it probabely wont do much good.


Originally posted by Sonny Gill:
http://www.pairprogramming.com/

This doesnt quite look like something for me

What specifically looks like it isn't for you?


Well the part that the other person has to sit right beside me all the time I code.
But, I wouldn't mind having very short cycles of coding and reviewing, even as small as 15 minutes. I wonder if that can be considered PP.

I think a lot depends on who your teammates are. We all know the coworker who has a knack for disturbing you for something trivial right when you are concentrating really hard on something. Would PP work for somebody like that? Than again, that person should probabely not be on the team anyway

You probabely have come accross what Joes says about programmers being in the zone. http://joelonsoftware.com/articles/fog0000000068.html
I dont totally agree with what he says about having very private offices, but it is worth a read.



The main advantage of PP over conventional peer review is that suggestions for improvement come while the code is written, not after it is finished. That has several consequences:

- it's much easier to accept a suggestion from someone working with me on *our* code, than from someone nitpicking on *my* code that I supposed to be finished;
- it's much less effort to incorporate improvements into the code while it's currently being formed than when it's already finished;
- when we discuss the code while we write it, we get much faster feedback on what the result of the improvement looks like, and therefore can discuss wether it really was an improvement and/or wether we now see even more ways to improve it.



Agree with all of the above. Effective peer review is easier said than done. If the amount of code to be reviewed is really large, the reviewer starts to cut corners, and the person who wrote the code in the first place, has probabely moved on to something else, and is not very motivated to go back and evaluate the proposed changes or make the changes in the original code.
U Patel
Greenhorn

Joined: Sep 28, 2004
Posts: 18
Originally posted by Ilja Preuss:


Well, that's actually what rally teams prefer to do.

I actually have never seen - and can't imagine - a design that I don't learn something about while coding it.

And if I really felt like coding something the 5 millinon'th time, I'd wonder wether I'm missing some opportunity for reuse. But perhaps I'm just not understanding what you wanted to express using that analogy...


When I say "peer review", I am looking at it more from componant design perspective. if a piece of work is being designed by two developer or team will be much more effective than looking at the code over the shoulder.Code is made up of syntaxes. Not saying that code doesn't matter. Just a different perspective that if the logic to solve the problem will be considerd at the componant design time will produce good code.

Wouldn't it be wise to discuss the class diagrams upfront that developers came up with. This is the place where questions would arise like why AbstractClass and not interface? why factory when singleton is need at that point and time? This discussions will define a very fine design that would eventually end up with good code.


As far as your comments about reuse goes, Don't you think that given a class defined with its responsibilities would bring this point upfront?
friso dejonge
Ranch Hand

Joined: Jul 11, 2002
Posts: 162
hi all,

Kind of funny, but I havent heard anyone mentioning the downsides, like testing the keyboard on the other persons head. During studies (about 10 years ago) we had to do something like PP, but my partner and I could not stand each other any more after 2 or 3 hours. Even though he was generally a nice person.

That said, I have to say that we always discussed the way we were going to do the coding. After this discussion, a 'viewer' was only allowed to point out typo's. That worked fine, but because we both had strong opinions this wasn't real PP.

Does anyone else have the same sort of experiences ?

cheers,
friso


swimming certificate (A & B), shoelaces diploma, and some useless java ones.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Warren Dew:
If a loner doesn't want a job that's overly stressful, they probably shouldn't take a job as an XP programmer, any more than they should take a job as a telemarketer.


Or he should simply search an XP team that lets him PP just as much as he feels comfortable doing.

Despite loners being in the minority in the overall population, I think most good programmers used to be loners, because non-loners didn't do well in the job: they got bored and inattentive when alone, and so didn't do a good job during long hours of programming or debugging.


I wonder how many of those "loners" are actually "loners by heart", and how many are actually *trained* to be loners by the conditions on their working place.

Pair programming in XP is largely a way to allow non-loners to be productive programmers as well, especially as enough software people are now required that there aren't enough loners to fill the ranks.


Is it? Where do you get this from?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sonny Gill:
Do you find that for PP to work, esp. for introverts, the person they pair with has to be 'just right' for them?


Being a good partner always needs skill. And certainly you need somewhat different social skills for different partners - not only depending on wether he's an introvert or not.

Two people pairing up to program must both have something to offer to each other. If there is a big gap in skills, for example, it probabely wont do much good.


In my (and not only my) experience, everyone has something to offer (if he cares to speak out). No single person knows only a subset of what someone else knows. And if everything else fails you can still ask questions. Just having to explain something to someone can give you valuable new insights.

And then there is this story of Kent Beck having his young daughter ask him "do you have a test for that" every couple of minutes...

Well the part that the other person has to sit right beside me all the time I code.


That's not PP. PP is when you both code together. Seriously.


But, I wouldn't mind having very short cycles of coding and reviewing, even as small as 15 minutes. I wonder if that can be considered PP.


I wouldn't call it PP; but I wouldn't object to calling it "better than nothing"...


I think a lot depends on who your teammates are. We all know the coworker who has a knack for disturbing you for something trivial right when you are concentrating really hard on something.


Uh, where do you all know me from?

Would PP work for somebody like that?


Not very well, in my experience. That somebody had to learn to give his partner some more room. I hope I did.


You probabely have come accross what Joes says about programmers being in the zone. http://joelonsoftware.com/articles/fog0000000068.html
I dont totally agree with what he says about having very private offices, but it is worth a read.


Yes - most of his articles are quite god, as far as I remember.

Interestingly, most programming pairs report that they experience some kind of "flow"/"zone", too. And it's often more stable, because typically only one of the developers needs to take care of the disruption and can be "pulled bag into the zone" by his partner easily.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by U Patel:
if a piece of work is being designed by two developer or team will be much more effective than looking at the code over the shoulder.


PP is *not at all* about "looking over someones shoulder". That's a very common misconception.


Code is made up of syntaxes. Not saying that code doesn't matter. Just a different perspective that if the logic to solve the problem will be considerd at the componant design time will produce good code.


That's not my experience at all.


Wouldn't it be wise to discuss the class diagrams upfront that developers came up with. This is the place where questions would arise like why AbstractClass and not interface? why factory when singleton is need at that point and time?


You are free to do that - it's not at all incompatible with PP.


This discussions will define a very fine design that would eventually end up with good code.


So are you saying that coding the design is a fully/mostly mechanical activity? If so, I'd agree that PP does make much less sense. Never seen it happen and have problems imagining it, though.


As far as your comments about reuse goes, Don't you think that given a class defined with its responsibilities would bring this point upfront?


Not all of those opportunities, no. Code reuse can happen at a very small level that you are quite unlikely to discuss before starting to code, in my experience.

It can already happen when you notice that you have written

getFolder() + "/"

at two places.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by friso dejonge:
Kind of funny, but I havent heard anyone mentioning the downsides, like testing the keyboard on the other persons head. During studies (about 10 years ago) we had to do something like PP, but my partner and I could not stand each other any more after 2 or 3 hours. Even though he was generally a nice person.


I am lucky enough to have a very good friend working with me in the team. After PP'ing for two consecutive weeks, we recently were on the brink to killing each other.

That's one of the reasons most teams prefer to switch partners several times a day.
U Patel
Greenhorn

Joined: Sep 28, 2004
Posts: 18
Originally posted by Ilja Preuss:


Not all of those opportunities, no. Code reuse can happen at a very small level that you are quite unlikely to discuss before starting to code, in my experience.

It can already happen when you notice that you have written

getFolder() + "/"

at two places.


No it won't if you class's responsibilities are predefined less likely to happen.
[ October 05, 2004: Message edited by: U Patel ]
Linda Rising
Author
Ranch Hand

Joined: Jan 21, 2001
Posts: 76
I like all this interesting discussion!

I would like to ask the skeptics (who aren't convinced that PP is at all worthwhile), if they can think of any situation at all where PP *might* be a good idea??
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Well, I am not exactly a skeptic, but just trying to understand PP better..

One situation that immediately comes to mind is while refactoring an existing module that is a bit messy. The code is working, and you want to move things around, make changes in small steps to improve the whole thing without breaking any functionality. I think that PP would definately help in that.

And another one would be while trying to track hard to find bugs. While I try to find it, my partner keeps an eye on anything I might be missing and thinks about other ways of finding it. At the same time, having two people evaluating the bug-fix to be applied increases our confidence that it wont have any unintentional side effects.

Cheers
[ October 05, 2004: Message edited by: Sonny Gill ]
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Originally posted by Ilja Preuss:

Interestingly, most programming pairs report that they experience some kind of "flow"/"zone", too. And it's often more stable, because typically only one of the developers needs to take care of the disruption and can be "pulled bag into the zone" by his partner easily.


Hmm..that is really intersting..never thought of that....something I would like to test for myself.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30506
    
150

I've done some PP in limited scenarios. For example, when there was something tricky/new to do or when one person was showing another how to do things.

I'm convinced PP has some value, but I'm not convinced it has value all the time as XP advocates. Could someone who does PP regular explain the value of doing something routine in a pair? (I realize there is some benefit to the other person checking for errors, but I can't see how this warrants twice the effort.)


[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
Linda Rising
Author
Ranch Hand

Joined: Jan 21, 2001
Posts: 76
We used to believe that PP took twice as long as working alone. It makes sense. Now there is data from experiments to show that this is not the case. It's true that there can be a learning curve for some pairs, but the interesting result is that there isn't much of an effort penalty and sometimes there is no penalty. What the data shows is that the quality of the solution is greater than it would be for either partner coding alone. Laurie Williams has an excellent book on the subject with lots of data and intriguing stories -- see Pair Programming Illuminated.
friso dejonge
Ranch Hand

Joined: Jul 11, 2002
Posts: 162
Hi,

I would like to ask the skeptics (who aren't convinced that PP is at all worthwhile), if they can think of any situation at all where PP *might* be a good idea??


Yeah, I am sceptical, but I can see the advantages as well for improved coding, and maintenance. Currently I am working in a maintenace situation and the amount of effort it takes for people to get up to speed with the solution that someone else actually created, is enourmous. This is basically an interesting twist that suddenly you have two people who know the solution and can fix or extend the program. So in that sense you save time. Not to mention that you probably get a solution with PP that adheres much closer to the Functional and Technical designs. So there are advantages. Like another writer said, switching partner looks like a good idea. thanks !
regards,
friso
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Pair programming! Intersting

Does pair programming mean two people always work together ? I feel that two people should meet only for review, otherwise it would be waste of resources.


Groovy
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Pradeep Bhat:
Does pair programming mean two people always work together?


If taken to the extremes, it means that every line of code is written by two developers sharing one keyboard, mouse and monitor. Most teams seem to settle on around 60-80% PP.

See http://www.pairprogramming.com/

I feel that two people should meet only for review, otherwise it would be waste of resources.


That's how many people feel before trying it. Fortunately, our project manager allowed us to try it for two weeks, nevertheless (the Trial Run pattern from the book, BTW). With results persuasive enough that we are now fully free to decide how much PP to do. (That's my Hometown Story for you.)
[ October 06, 2004: Message edited by: Ilja Preuss ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:
Could someone who does PP regular explain the value of doing something routine in a pair? (I realize there is some benefit to the other person checking for errors, but I can't see how this warrants twice the effort.)


- routine work often is boring and therefore more vulnerable to becoming inattentive; checking for errors might be quite valuable

- routine work often benefits from some amount of automation; in my experience a pair is more likely to be motivated to "break out of the routine" and tackle the automation job

- even in routine work you might benefit from some amount of creative customization

- cross-training: even when doing routine work, you can learn new things from your partner - for example that cool hot key you weren't aware of

- distribution of knowledge; project risk is strongly reduced if more than one person knows about every single thing
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

If taken to the extremes, it means that every line of code is written by two developers sharing one keyboard, mouse and monitor


Does this mean we need less computers in office?

:roll:

Has pair programming used in many projects before(Thanks for you story Ilja) or is it a new concept?
[ October 06, 2004: Message edited by: Pradeep Bhat ]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

What if there are disagreements? How do we handle them.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
Does this mean we need less computers in office?

It could mean that. However, since most teams don't pair 100% of their time, they most likely need personal computers -- if for nothing else then for reading email (something you probably don't prefer doing with the other guy right there...).

Originally posted by Pradeep Bhat:
Has pair programming used in many projects before(Thanks for you story Ilja) or is it a new concept?
Yes, pair programming has been used in many projects before. Probably for, I don't know, 30 years already?
It's just that XP has made such a big noise about taking pair programming to the extreme that people from both sides of opinions have started to voice their thoughts. If you're interested in the history of pair programming, Google for Laurie Williams.

Originally posted by Pradeep Bhat:
What if there are disagreements? How do we handle them.
Just like you would handle disagreements in a non-pair programming scenario (hopefully a civilized discussion...).


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
Just like you would handle disagreements in a non-pair programming scenario (hopefully a civilized discussion...).


Yes. Or with an experiment - remember, you are sitting on a keyboard, it might well be faster to try it both ways than discuss which one you should choose for half an hour.

And sometimes it's really just a matter of taste - tossing a coin has worked well for us in those cases. Seriously!
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30506
    
150

"- routine work often benefits from some amount of automation; in my experience a pair is more likely to be motivated to "break out of the routine" and tackle the automation job"
Ilja, Thanks! I found this one to be the most interesting.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Ilja Preuss:

Or he should simply search an XP team that lets him PP just as much as he feels comfortable doing.

Maybe he should make sure the "XP team" also allows him to write tests only as much as he feels like, and claim individual code ownership over pieces of code he doesn't want others to touch, and not bother running the tests if he's pretty sure his new code works already? Doesn't sound very eXtreme to me.

I wonder how many of those "loners" are actually "loners by heart", and how many are actually *trained* to be loners by the conditions on their working place.

During the time period I'm referring to, few programmers had, say, any kind of social life - and that was by choice. They were the kind of people who opted out of high school parties and college beer bashes because they didn't really care to be in the company of other people very much. Part of the reason they made good programmers was that they really preferred associating with machines to associating with people.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Jeanne Boyarsky:

(I realize there is some benefit to the other person checking for errors, but I can't see how this warrants twice the effort.)

Over the course of an entire project, from inception to release, how much time do you spend writing code, and how much time do you spend testing, debugging, and fixing it? For most people, it's maybe 25-30% writing code, and 70-75% debugging. Spending twice the effort writing code can easily pay off, if it cuts the number of bugs in half.

For people whose code tends to run correctly the first time, pair programming is more questionable. Such people are not common, however.
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Originally posted by Ilja Preuss:

Two people pairing up to program must both have something to offer to each other. If there is a big gap in skills, for example, it probabely wont do much good.



In my (and not only my) experience, everyone has something to offer (if he cares to speak out). No single person knows only a subset of what someone else knows.


What I meant there was that if the skill levels are comparable, they will get more overall benefit from pairing up.

OTOH, If there is a huge gap in skills, the benefit wont be enough to justify the more skilled person spending his time pairing up with the other person, unless the objective was to teach the other person in sort of a master-apprentice arrangement. I am not saying that there wont be any benefit, but will the benefit justify the cost?
There is, I suppose, no definite answer to that, and it has to be decided on a case by case basis.

Interestingly, I enjoy PP quite a lot. I wouldn't want to do it 100% of the time, but wouldn't object to 80%.


Ilja, what criteria would you apply to decide which 80% of the code to choose for PP?
The same criteria could probabely be used by someone to decide to do 20% or 50% of the coding using PP, depending upon how much of it they feel comfortable with.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Who decides who should pair up ? :roll:
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Is there any name for programming where three or more get involved?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Warren Dew:
Maybe he should make sure the "XP team" also allows him to write tests only as much as he feels like, and claim individual code ownership over pieces of code he doesn't want others to touch, and not bother running the tests if he's pretty sure his new code works already?


Well, a team certainly needs to find the balance between doing what serves the team and respecting personal individuality.


Doesn't sound very eXtreme to me.


And I wouldn't want to be on a team which's goal it was to be extreme.

What I would want to be on is a team that wanted to try practice to get good at them and then decide how much to them based on that learning.

During the time period I'm referring to, few programmers had, say, any kind of social life - and that was by choice. They were the kind of people who opted out of high school parties and college beer bashes because they didn't really care to be in the company of other people very much. Part of the reason they made good programmers was that they really preferred associating with machines to associating with people.


Actually that sounds a lot like me in my younger days. For several years my father made fun of the fact that I read the several hundred pages of "Introduction to Pascal and UCSD Pascal" in one weekend - "like other people read mystery stories".
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
Who decides who should pair up ?

The pairs themselves. In some cases, especially when the team is trying pair programming for the first time, it might be necessary for someone to initiate switching of pairs and even select the pairs. After a week or two, the team is most probably pairing up without guidance.

Originally posted by Pradeep Bhat:
Is there any name for programming where three or more get involved?
Sorry, no. Although people do use terms like "triplet programming", it's more a joke than a name for a serious development technique. However, that is not to say that getting together with three (or more) developers in front of a single monitor/keyboard wouldn't be a good idea -- I've often seen and participated in such moments of gathering. It's just that 99% of the time that amount of eyeballs on a single monitor is not really necessary.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: blog of Kathy - Pair Programming is NOT always a choice