Fog Creek Software
Discussion Board




eXtreme, life-altering pair programming

I thought it would be interesting to point this Passage out.  This spontaneous pair programming session occurred between Richard Stallman and Guy Steele.

' "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.'

At the end of:
[ http://www.oreilly.com/openbook/freedom/ch06.html ]

Sammy
Friday, May 10, 2002

An interesting incident.  Steele's final comment on the session is also interesting:

"...it was a great experience, very intense, and that I never wanted to do it again in my life."

mackinac
Friday, May 10, 2002

OTOH, perhaps if he had the chance to try it again, he'd feel differently.  And, perhaps he'd feel differently about pair programming with someone other than Stallman.

Brent P. Newhall
Friday, May 10, 2002

Mackinac, I find it wierd that you take every chance to attack pair programming but you have never tried it. correct? Maybe it's my misinterpretation. It just seems like there are quite a few threads devoted to debunking pair programming.

I saw a thread earlier in whcih a poster "required" empirical scientific data showing clear measurable benefits of pair programming by a third party before they would even consider it. So basically if i did a quiznos type study with a graph showing increased productivity and "increased lifestyle happiness" it could sway them.

Amusing. If only all of lifes decisions could be studied by scientists to determine what is best for me. I could justify my leaving early by showing my graph of increased my well being in incremements of "happiness units" and show how that  helps drive production.

So basically what I'm saying is: why don't you try it for yourself and see if it works in your environment. Because if you have never tried it/analyzed it for yourself how can you comment on it's effectiveness?

I know I know, you simply have "doubts" :-] It's good to be skeptical in this profession.


As for Stallman. I'm still not sure what to make of him. The world needs zealots but I'm not sure I'd like to be pair programming with one of them :-)

Ian Stallings
Friday, May 10, 2002

If you are interested in hot 2 on 2 pair prrogramming email stayhjard11@yahoo.com. ukranians, asians, pregnant moms, software pundits first 10 mins free.

dead horse
Friday, May 10, 2002

dead horse, you do appear to be beaten a lot.  It just seems that a lot of conventional wisdom turns out to be very strange, and a lot of times people take possible Resources and turn them into obstacles.

I know that sounded ontopic only in my own mind, but I am finally done with a stupidly long coding spree and will sleep for a couple days. ;-)

Sammy
Friday, May 10, 2002

>>>Mackinac, I find it wierd that you take every chance to attack pair programming<<<

Wierd?  Attack?  I am quite skeptical of it and if someone makes a statement supporting it I would like to know all the details of their experience.

>>>but you have never tried it. correct?<<<

That is true.  Unfortunately that is the case with most people posting on this topic.  Those who have experience are a resource for those of us questioning it.  I hope my postings aren't really read as attacks on them.  However, if they do post I am likely to question those postings to get at the details behind them.

Actually, I recalled that my first ever class in computer programming was sort of pair programming.  Students were paired up and expected to work together.  This was because it was only one credit hour and doing it alone was thought to be too much work.  I ended up doing all the projects alone because that was easier than getting together with my partner.

>>>Maybe it's my misinterpretation. It just seems like there are quite a few threads devoted to debunking pair programming.<<<

There have been several threads discussing pair programming, with various viewpoints expressed.

>>>I saw a thread earlier in whcih a poster "required" empirical scientific data<<<

That was not me.  Some studies of development methods may be useful, but it is difficult to  be quantitative.  I think that request was excessive.


>>>So basically what I'm saying is: why don't you try it for yourself and see if it works in your environment.<<<

If only life were long enough.  As the saying goes: "The intelligent person learns from his mistakes, the wise person learns from other's mistakes."  I am trying to gain a little wisdom from others experiences.

>>>Because if you have never tried it/analyzed it for yourself how can you comment on it's effectiveness?<<<

How exact does the trial have to be?  I am extrapolating from my own experiences and trying to compare to the experiences of others.  Too often in these discussions someone will say they think XP is great, then on questioning it turns out they weren't really doing XP, or weren't really doing full time pair programming.

>>>I know I know, you simply have "doubts"<<<

Well, yes, I do.  I have had experience working in a poor environment where any change would seem like an improvement.  And I have been fortunate enough to work in a high quality traditional (individual programmer) environment.  If someone posts saying they tried pair programming and think it's great, I want to know "compared to what?".

>>>It's good to be skeptical in this profession.<<<

http://www.ncas.org

>>>As for Stallman. I'm still not sure what to make of him. The world needs zealots but I'm not sure I'd like to be pair programming with one of them :-) <<<

Selecting pairs is a problem you don't have with individual programming.  One would like to know how it can be done properly.

mackinac
Friday, May 10, 2002

I tried pair programming for about a week, I worked with someone I like, and who's ability I respect. Eventually I got really sick of it, and felt like saying - go away, I'm sick of your permanent presence, I want to read my email, I want to make a phone call, I want to goof off for a while, I want some space get away from me, I dont want to come into work anymore because you'll be here breathing near me and taking up my personal space, all the fun will be gone because I cant be free to do things the way I like, we will be a two cylinder coding machine and I want to be a one cylinder human being, enjoying my life and career instead of coding for the man with you right there every fucking minute of the day listening to me talk to my girlfriend on the phone eager to write another line of code together, get the fuck away from me, I hate you. You slow me down, you speed me up, you make me less human. I was just about ready to tell him to fuck off, but then I realised why I liked him in the first place, he had already gone and was goofing off with some web stuff about as far away from me as he could physically get. Happy again.

Tony
Saturday, May 11, 2002

Oh and as regards this Stallman character, anyone who thinks "that all software should be free and the prospect of charging money for software was a crime against humanity"
should be burned at the stake.

Tony
Saturday, May 11, 2002

I'll be brief since this dead horse has been flogged many times before.

I've never done pair-programming before.  I'm skeptical of it as a magic-bullet, but I'm sure it works for some people and for some projects.  I wouldn't hesitate to give it a shot for some situations.  There are some problems which require quiet reflection and individual experimentation, and then there are problems that are solved by cranking out gobs of code.  One lends itself to pair programming a lot better than the other.  There is a time and place for everything under the sun.  I think that neither side of the debate is right or wrong, they're just not seeing both sides of the same coin.

Alyosha`
Saturday, May 11, 2002

Mackinac:
I guess I posted to soon and misjudged your position and apologize for the assumption. I wasn't refering to you when I said many threads were devoted to debunking XP or the poster requiring empirical evidence proving XPs worth. I should have made that clear.


My experience with pairing - I found that when I was driving I could get more accomplished if someone more experienced was with me. It was my first time coding EJBs and also using XP practices so it helped a lot. On the other hand when I wasn't driving and I was paired with one partner constantly I found myself day dreaming and not paying attention. My personal view is pair programming is great for debugging, knocking out prototypes/spikes, and  teaching newbies good practices but maybe not so good when you start to do the same things over and over again. After 100 EJBs each one started to look exactly the same when I paired and eventually we split up because we found it more productive at the time, as the project wound down. So pairing is certainly up for debate. But I can honestly say that the experience I had in that environment was the best I have had in my career. We cranked out a large app in 6 months with a bug count lower than I've experienced in past projects and the client was was happy.

Ian Stallings
Saturday, May 11, 2002

Tony,

That was superb.  Simply awesome.

Nat Ersoz
Sunday, May 12, 2002

Tony,

That was terrible, simply horrible.

That has nothing to do with pair programming.

No one, not even Ward and Kent, pair for more than two or three hours.  You don't sit around, taking a break, talking to you girlfriend while you pair.  Yes, if you did, it would suck.  But you don't, so it is a straw man.

Pair, get your code done, then go talk to your girlfriend, chill, and play Tetris.  Geesh.

John Lindsey
Sunday, May 12, 2002

Yes, well, I like my space and thats final. It was'nt horrible, just a reaction, I tried it and I really, really hated it, I'm good at my job, other people just get in the way, not in a nasty way. By all means discuss design issues with somebody else, coding strategies, structure, interfaces, etc , but when it comes down to doing it trust somebody to do it, no hand holding should be required.

Tony
Sunday, May 12, 2002

Ian, Tony, et al,

Thanks for the postings.  Those are the sort of personal experiences that I was hoping to hear about in this discussion.

Nevertheless, I am about saturated with input on this topic for now.  There is a pile of books by McConnell and others on various SWE topics here that I need to work on.  Any more reading about XP will have to wait a bit.

mackinac
Sunday, May 12, 2002

Tony,

it sounds like you where PP with the same partner for eight hours a day. I would get sick of that too - in fact I am currently in the situation of just having one partner and we pair only approximately six hours a day and need very frequent breaks.

I do like pair programming *much* more when being able to switch partners every couple of hours.

Ilja Preuß
Monday, May 13, 2002

Ian,

"My personal view is pair programming is great for debugging, knocking out prototypes/spikes, and teaching newbies good practices but maybe not so good when you start to do the same things over and over again. After 100 EJBs each one started to look exactly the same when I paired and eventually we split up because we found it more productive at the time, as the project wound down."

In my experience, when pairing gets tedious, you most probably missed an opportunity to automate. For example, couldn't you have been even more productive by writing a script to generate most of the EJBs code?

Ilja Preuß
Monday, May 13, 2002

"[...] and then there are problems that are solved by cranking out gobs of code."

I *never* worked on a problem where "cranking out gobs of code" by hand was/would have been the most effective solution - and I can't imagine one. Seriously.

Ilja Preuß
Monday, May 13, 2002

Ilja,
I think we did miss an opportunity to automate. We could have created a good portion of the EJB code using scripts. They are basically the same architecture and I think we actually decided on automation, but unfortunately as the project wound down but we got sidetracked by internal company problems that eventually lead to that companies demise. We could deliver solid products on time with low bug counts, but that really means nothing if you have no sales. This effected our work and I'm sure also contributed to my own malaise and it's hard to be objective in times like that. But I did carry away practices that I love to use such as unit testing everything, automating everything I can, continous integration and daily builds, refactoring, etc. It was quite a learning experience for me.

Ian Stallings
Monday, May 13, 2002

Ian,

thanks for the report!

Ilja Preuß
Tuesday, May 14, 2002

Ron Jeffries had an amusing quote on the xp mailing list a few days ago. Paraphrased, "it's called pair programming, not pair living!" It is recommened that you're only paired during actual coding tasks. Obviously that doesn't make up the entirety of our days, so we also need personal spaces to perform other tasks.

Also, it's recommended that you change partners frequently, even more than once a day. This might help lessen the partner annoyance factor. ;-)

Tim Moore
Tuesday, May 14, 2002

>>>Paraphrased, "it's called pair programming, not pair living!" <<<

The reading I have done so far (a few web pages) indicates that XPers advocate placing all developers in a bull pen or "war room" environment.

Irrespective of whether or not one is pair programming with one person continuously, there is no personal space in such an environment.

mackinac
Tuesday, May 14, 2002

>>The reading I have done so far (a few web pages) indicates that XPers advocate placing all developers in a bull pen or "war room" environment.  Irrespective of whether or not one is pair programming with one person continuously, there is no personal space in such an environment. <<

From the experiences I've read of, the "war room" is not the only space in the building, though.  There are cubby-holes or cubicles or personal offices or whatever around and/or outside the war room.  Developers can break off into these private areas.

Either way, we're arguing theory when the proof is in the practice.  XP is about aggressively trying out new practices for improving software development, even if they may not work.  Whether it's better to keep programmers together constantly or to let them break off is moot if one is unwilling to attempt the basic principle.

IMHO, at least.

Brent P. Newhall
Thursday, May 16, 2002

>>>From the experiences I've read of, the "war room" is not the only space in the building, though. There are cubby-holes or cubicles or personal offices or whatever around and/or outside the war room.<<<

I reviewed a report of a study on a warroom environment.  It did mention that hotelling cubicles were available.  These at least provided a place to make phone calls.  Although the cubicles provided PCs, developers would come in off hours to do work when they wanted a quiet work environment.

mackinac
Thursday, May 16, 2002

Tony, Ian,
  you summed up a lot of the fears I have with Pair Programming. I have seen jobs posted where they really advocate the pair side of things. It comes off a bit creepy because I can't shake the feeling that managers adopt it as some cheap way of cutting down on resources: PCs, desk space, phones. Also PP would cut down on employees personal use of internet/phones/email etc. Just seems a bit ugly.

  I got friends who have done PP, and very successfully too, but PP was a tactical decision to a specific problem, not the default MO. If anything PP is more resource expensive: the members need their own space and possibly a shared work area also.

  I want to appreciate PP, as it could be really useful where I am working now as a way of mentoring & sharing knowledge (and getting code in decent shape). Might even practice it myself on a new project. I just can't shake the feeling that it is used for its side effects, and that any attempts to get it to work right by calling in resources would eb viewed with suspicion.

 

Richard
Monday, May 20, 2002

A couple of comments,

1. If you want to read on some academic research into pair programming, Laurie Ann Williams
  http://collaboration.csc.ncsu.edu/laurie/
wrote her dissertation
  http://www.cs.utah.edu/~lwilliam/Papers/dissertation.pdf
on the subject.

2. If you look at how student assignments in collage / university are often allocated and fulfilled you'll notice that students often engage in PP without calling it by name. So, it *is* a natural way of collaborating, albeit not for extended durations.

Amir Kolsky
Thursday, May 23, 2002

Amir, I read those articles and replied in another post, which I'm going to post here (sorry for the redundancy).
=====
However, reading through the specific studies, much of the code and evaluation was done in a university setting. The exceptions to these being Ken Beck's and cohorts already documented experiences.

For example, I am skeptical about the U. Utah experiment which found that PP resulted in only a 15% increase in man-hours worth of development and a corresponding 15% reduction in code defects.

The first thing that should be a tip-off is that the time scales are measured in elapsed time. If this is indeed the case then it takes a team of 2 more time to complete a task than a loner. In the best case, pairs completed the task at 80% of the loner. That means a more than doubling of programming assets for the task. Our company cannot afford that sort of productivity hit.

Secondly, the case for XP assumes that unit tests don't exist outside the non-methods universe (OK, I'm exagerating). Nevertheless, how does someone deliver code that has predefined performance criteria (as was the case in the Utah study) and not get a perfect score? How does this happen? You know the test scoring criteria, and yet you do not test to that criteria? Again, I'm suspicious.

Finally, I agree that collaboration is a powerful tool (hence my ramblings in prior posts over the virues of cubes over offices). It is not my attempt to discount collaboration.  However, I found the studies to be far too friendly toward pair programming rather than maintaining a healthy skepticism.

Nat Ersoz
Friday, May 24, 2002

*  Recent Topics

*  Fog Creek Home