Fog Creek Software
Discussion Board




Pair Programming - trying to clear the air

I seem to be having communication issues, so I'm going to try again.

For those that feel that pair programming is 100% unworkable, of course the first question is:
a) Have you tried it?

Of course, this goes back to the age-old mantra of "don't knock it until you've tried it." I used to be really conservative about my programming skills - every new paradigm was met with distrust and avoidance. I have, of late, worked on fighting that in myself and evaluating new things simply on their merits. Nine times of out ten, this means trying it myself.

See my thread on Typed Datasets - a few years ago I would've avoided them like the plague. This time I resolved to try them, work with them, and understand them. As it turns out, they're not appropriate for the webwork I'm doing, but there are times when I can see they would be a good toolset to use.

Linux? I tried. Oh man I tried. Had a linux firewall for 18 months. Did everything by hand. I finally gave it up when I had to recompile the kernel to get a USB mouse working and my requests for assistance were met with derision. Instead I spent $80 on a linksys firewall. I may go back to a linux firewall soon, since I have some multiple IP requirements that aren't met by the linksys.

Java? Built some applets, worked on a few beans. I don't have a current need for it, but I understand the potential power of the language.

So - until you've worked a week sitting next to someone, I'd say you really don't have a place saying "Pair Programming can never work"

Then...

b) If you *do* try, and it *doesn't* work for you, you can say "Pair Programming isn't for me." I *still* say you're being excessively presumptuous saying "Pair Programming can never work."

*I* believe in pair programming, despite having never done it, because I see the power of collaboration, and I think that power would translate to PP very well PROVIDED THE CODERS ARE OPEN-MINDED AND THERE'S GOOD MANAGEMENT INVOLVED.

Some people listen to music when they code, some people need silence. Some people enjoy guerilla coding, some people prefer a slow, methodical approach to everything. Some people like working up proofs of concept, some people prefer implementation, some people like testing.

Some people will benefit from Pairing, some won't.

"Pairing can never work" is an opinion, not a fact. My post here is my opnion, not fact. Everyone is different and different things work for different people is about as close to a fact as you'll find here, except for maybe this:

People who generalize to the IT industry based on their own expectations and experiences should really think twice about what they are saying. ;-)

Philo

Philo
Tuesday, June 03, 2003

[until you've worked a week sitting next to someone, I'd say you really don't have a place saying "Pair Programming can never work"]

Philo,
I never said it can never work. I said I think it would be helpful on occasions. I said forcing everyone to do it all the time is a dumb idea.

The Real PC
Tuesday, June 03, 2003

Yep. I agree with you there.

Philo

Philo
Tuesday, June 03, 2003

I'm not a fan of open-ended cliches such as "don't knock it until you tried it." I've never eaten a cockroach, but I feel safe in my assumption that I won't find it very tasty.

Likewise, I've had to spend time working with other people on one computer. Not pair programming, per se, but more of just situations that arise. I know one of the rules of pair programming is that the programmers have equal skill, but nothing drives me nuttier than watching a skilled developer who still can't type hen-peck on the keyboard. It just kills me. It's a flaw on my part, but....

That's minor compared to the times when I just need to think something through and I don't need someone breathing my air while I'm thinking.

Everything in moderation. There are plenty of advantages of having developers work together for a period of time. But to mandate that all programmers must work together for an 8 hour day is not necessarily a good idea.

Mark Hoffman
Tuesday, June 03, 2003


Mark,

I challenge your assertion that you think better alone.

Anyway, when you pair it's not like you're joined at the hip. Of course you can take time apart. But if code is being written, then it's two people at the keyboard.

Bruce
Tuesday, June 03, 2003

[But if code is being written, then it's two people at the keyboard.]

That is the absolute rule that we don't like.

The Real PC
Tuesday, June 03, 2003

It depends on how you implement it.

You could have a "Pair Only" shop, deparment, project, or team. Obviously your company is going with a "Pair Only" project (and late in the game, by edict).

Personally, I believe that if you're going to pair, then that pair should only work pair-style. To do otherwise would defeat the purpose - pair for two days, then let the programmers work independently? Then if they try to pair again it's going to be all catch-up.

This is another potential pitfall in pairing - you're locking two people to working together, which can complicate days off and work schedules. IMHO, it is simply another management challenge - you want to be sure there's tasking available for people when their partner's not in. This isn't that tough to do, but it *does* take effort.

Philo

Philo
Tuesday, June 03, 2003


[That is the absolute rule that we don't like. ]

Don't be so pedantic. Even we aren't that literal. We pair for all new code (no exceptions) but defects are on an as required basis.

But I question your basis for objection. Do you believe that you can produce better code than a pair? I doubt it. Faster? I doubt that too.

A lot of people point to a potential partner's social graces. Look, if one of your team mates smells bad, or talks about the Matrix all day long, then you already have an issue. Maybe PP will actually force the team to face it.

It's hard not to conclude that your basic objection to PP is rooted in fear. Fear of ego bruising to be specific.

Bruce
Tuesday, June 03, 2003

I taught for 31 years, many of them teaching programming.  In every class there were people who HAD to work alone, and were very successful, and others who HAD to work in pairs, and ALSO were successful.  I, personally, am programming now because I enjoy it and if I had to spend my time sitting and watching someone else program the ideas that we developed jointly I would quit, because that isn't why I'm programming.  I understand, also, that if you are just programming to eat, then anything that puts food on the table is fine, including PP.  I don't know if I would be more productive under PP, but it isn't why I'm here.

Barry Sperling
Tuesday, June 03, 2003

"It's hard not to conclude that your basic objection to PP is rooted in fear. Fear of ego bruising to be specific. "

Wow. So we don't agree with you and that makes us egomaniacs? Way to change an intelligent discussion into a forum to insult people, Bruce. Why don't you run along and let us mature adults have a rational discussion? kthxbye.

Not everyone thinks PP is Godsent. Get over it.

If it works for you, that's great. With all of the time that PP has saved you, you might invest some time in learning how to disagree with people without coming across as a complete asshole.

Mark Hoffman
Tuesday, June 03, 2003

[But I question your basis for objection. Do you believe that you can produce better code than a pair? I doubt it. Faster? I doubt that too.]

This would depend greatly on the pair.  Take any two developers where I work minus two or three that I exclude from your selection, and I'd say yes. 

Also, I don't have to code faster than the pair.  I just need to code faster than half as fast as the pair.  Take those two or three that I excluded above, pair them together, and they aren't going to code twice as fast as me.  Their code might be better, but not enough so to justify tying them up on one single task.

Owen
Tuesday, June 03, 2003

>Also, I don't have to code faster than the pair. 
>I just need to code faster than half as fast as the pair. 

You're forgetting about the impact to quality of PP.

Let's say that 2 programmer's PP-ing are as fast as 1.3 programmers individually.

When you factor in the lower error rate, and the time spent fixing errors and de-bugging, PP is cheaper - in most cases.

Sure, there are exceptions, but, well ... they are exceptions.


regards,

Matt H.
Tuesday, June 03, 2003

"but defects are on an as required basis"

wow.  you must have one of them extra fancy compilers that lets you fix bugs without changing code, because the XP rule is NO SOLO CODING.  NONE.  NADA.  ZILCH.  ZIPPO.

I've never said pair programming CAN'T work.  Just that I would never be a part of it.  I'd rather dig ditches (actually that's quite fun if you have the right tools:  http://www.northerntool.com/images/product/images/188040_lg.jpg )

Again, let's not confuse collaboration or hard-assed-multi-person-bug-fixin' with a requirement that you share a computer with someone else for 40 hours / week.

itchy
Tuesday, June 03, 2003

"Look, if one of your team mates smells bad, or talks about the Matrix all day long, then you already have an issue. Maybe PP will actually force the team to face it. "

And how does this help productivity?? Forcing HR issues down to the programmers? (The people that are typically the least skilled in intra-personal issues?!)

Anyway, I think it's great for productivity to have programmers spend a lot of their time bouncing ideas off one another and having a lot of time in code-review. I agree with the premise that two programmers tend to come up with better solutions and that programmers can often catch other programmer's mistakes in code review.

I'm just not sold on the idea of sharing a computer. I have no issue whatsoever in having my colleagues review my code. I have no problem whatsoever in being made to clearly explain my rationale for design or coding decisions.

For me, I'll stick with copius amounts of code review and communication.

Some Such Coder
Tuesday, June 03, 2003

[You're forgetting about the impact to quality of PP.]

No I'm not.  That's why I said:

"Their code might be better, but not enough so to justify tying them up on one single task."

If I am constantly running unit tests, why would my individually written code have so many errors in it -- errors so glaring that somebody watching me type would catch them?

Owen
Tuesday, June 03, 2003

Show me the data.  Show me where two people are more productive in total, working as a pair.  Compare that with working:
  - alone
  - alone and coming together as needed
  - alone with instant access to decision makers

We can all see cases where it can work.  But if you are going to put two exceptional developers together, their output, in total, must exceed 2.  Otherwise, their value is less, because I must put them on the same task and the process suffers when they cannot be together.

Also, by pairing people of similar skill, you get the equivalent of high school tennis,  most players are only as good as their competition. 

Can it work? Yes.  In most cases?  Show me the unbiased test results. It should be very simple to do.  Run a programming competition.  Pairs should beat non-pairs almost every time.  And they need to do so by a factor of 2+.

BlindFaith
Tuesday, June 03, 2003

"If I am constantly running unit tests, why would my individually written code have so many errors in it -- errors so glaring that somebody watching me type would catch them?"

Maybe it's just me, but I don't think so...
Have you ever built an app, done unit testing, prepared for a demo, beat the thing up and down and sideways, then set up for the demo, all calm and positive everything is ready...

...only to realize thirty seconds into the demo you've missed something, and prayed they didn't find it? Or the first thing they do breaks? ("What happens in the login if I don't put a user name?")

There's something about the human brain that "falls into" tracks - once you're working on something and have plotted out a course, you stay in that track and it's very, very hard to get out of it. It happens with everything - math, science, writing. That's why having someone review your work is always so critical. That's why we use flash cards to study and to mix them up - if you study from a page of questions, you get in the habit of answering the question in turn, but when you hear it out of turn, you don't know it.

That's why I tell my kids to review their homework backwards.

Another pair of eyes aren't stuck in your mental groove. And having them there while you're coding gives instant feedback:

"Why are you doing that that way?"
"Well, if the user wants to do [x], they can do this..."
"But what if they do [y] instead? Will it still work?"
"Oh crap..."

But now, instead of spending three days getting the code working to the proof of concept stage so this can come up in a peer review and you have to spend another two days reworking it, you hear the problem immediately and can code around it.

Philo

Philo
Tuesday, June 03, 2003

"Can it work? Yes.  In most cases?  Show me the unbiased test results. It should be very simple to do.  Run a programming competition.  Pairs should beat non-pairs almost every time.  And they need to do so by a factor of 2+."

FWIW, I think said programming competition would have to be something like "Produce an application to these specifications in four weeks" - simple "write a sorting algorithm" doesn't play on the strengths of pairing, which is fine, since that's not what we do for a living, either.

Philo

Philo
Tuesday, June 03, 2003

At an ill-conceived.com that I was working at, the new boss read a book on XP, and decided that clearly everyone should be pair programming all the time.

Whenever there was a particularly nasty multithreading problem to be fixed, it happened when the partner was taking a long lunch, going to the doctor, etc.

I discovered something: I didn't really like my coworkers so much that I wanted to spend 8 hours a day at the same desk arguing over the height of the monitor, editor choices that preclude the other from being able to type anything, trackball vs. mouse, how to debug each problem, when to use the unreliable debugger vs. when to write to log files, when to follow a hunch rather than being methodical, etc. 

And, no one had worked out what metrics to use to determine if this experiment was a success, so the entire thing was useless as far as I'm concerned.

I'd have to think long and hard before putting myself in that kind of a situation again.

Gustavo W.
Tuesday, June 03, 2003

I did some pair programming several years ago, when such practice was unnamed. It was the most rewarding and fun programming experience that I've ever had.  Lots of learning, and thinking. We managed to create a very clean and big design in a extremely short amount of time, without overtime. That piece of work lasted years (it was replaced just one year ago; it was a DOS application.)

Why this experience was so nice? I have some ideas: we were both competent, we have complementary skills, and we are good friends. We both share a thing for quality, and have big egos respecting our work: it was almost a friendly competition.

I have repeated this practice a couple of times in the recent years, with mixed results. I found that the most important thing is to be at ease with your partner and have similar goals.

(Any spelling corrections encouraged)

Leonardo Herrera
Tuesday, June 03, 2003

[I'll stick with copius amounts of code review and communication]

I have told my boss I thought we should have code reviews. I have put a lot of effort into communicating with co-workers. I realized asking questions was interpreted as a sign of weakness, and I was getting answers like RTFM or "try Google." I decided to become tough and independent like the rest of them.

I am all in favor of communication and collaboration, and the sharing of ideas. I want to learn from others, and am not an egomaniac or know-it-all. I am always interested in learning and improving.

Maybe they're trying PP here because they don't know how else to get these guys to communicate and ask each other for help.

I am in favor of XP, except for PP. I will change my mind if I see convincing data, and/or experience if for myself. I suspect PP works for some personality types, and that it may be better than the kind of lone coding practiced where I am now.

But for people like myself who already like to communicate and learn from others, it may not be needed.

Furthermore, some of us absolutely absolutely need a certain amount of time alone. Programming is a job that gives you that meditative tranquil space that, for some personality types, is as essential as air. I like being around people, but NOT ALL THE TIME.

The Real PC
Tuesday, June 03, 2003

See Real PC - You just admited why you REALLY don't like pairing. You don't like being around people that much. Well people in hell like ice water so deal with it.

trollbooth
Tuesday, June 03, 2003

Typical JOS forum index page view these days:

...
Am I frikking nutz?  forwardsi  (7 replies)
Experience dealing with real users? RealMan (-9)
Bonsai your pet - geek nirvana? CuttyHacky (4)
Pair Programming - Let's Discuss Pros and Cons Frodo (8,567)
Banishing Microsoft - necromancy anyone? Feklar (15)...
I mean - discussion of pair programming is acquiring the status of religion and politics. It only makes for flame wars.

The amount of heat generated seems to be inversely proportional to the constructivity of the discussions.

Bored Bystander
Tuesday, June 03, 2003

H1b visas are the cause of pair programming! Microsoft has it all locked down and Java sucks. Bella.

trollbooth
Tuesday, June 03, 2003

[You don't like being around people that much.]

Trollbooth,
How did you get that from my saying I don't like being around people ALL THE TIME?
You don't see a difference between the idea of not liking to be around people "that much" and not wanting to be around them "all the time?"

The Real PC
Tuesday, June 03, 2003

["It's hard not to conclude that your basic objection to PP is rooted in fear. Fear of ego bruising to be specific. "

Wow. So we don't agree with you and that makes us egomaniacs? Way to change an intelligent discussion into a forum to insult people, Bruce. Why don't you run along and let us mature adults have a rational discussion? kthxbye.]

Oh for god's sake, learn how to read a complete thread.

PC has stated from the beginning that he had not tried PP, yet thought it was a "really bad idea". Many of the objections I've heard from others include "smelly coworkers", "need for quiet time", "I'm a craftsman, not an engineer, dammit!", etc, etc. I've yet to see one objection based on something measurable. What else is one to conclude that fear is an issue?

Still, I got carried away. I don't have much patience for the "programming as art" crowd. I should know better.

Apologies to all.

Bruce
Tuesday, June 03, 2003

Heh, nice one Gustavo, I never thought of that.

What if your pair insisted on using emacs, as opposed to the one true path of vi?

punter
Tuesday, June 03, 2003


Ok, a lot of people are talking about comparing the output of a solo developer to a pair. One problem I've always observed is that people don't compare apples and apples.

If the challenge is to have a piece of software developed by a pair vs a solo programmer, then to be fair you would need to consider:

1) Time actually spent developing.
2) Time spent debugging issues directly related to the produced code.
3) Time spent in code reviews (which could be zero for the pair).
4) And to be really anal, time spent refactoring the code to implement later enhancements.

Personally, I think most pair would beat a solo on the first two points alone.

Bruce
Tuesday, June 03, 2003

Bruce - agreed. The test should be from receipt of a spec to delivery of a completed piece of functional software, and should include a score on bugs.

How come nobody gets this passionate about cubicles? I'd bet cubes have destroyed more productivity than pairing or the absence thereof...

Philo

Philo
Tuesday, June 03, 2003


Philo,

Your point about cubicles is a good one. It's probably the biggest obstacle to effective PP.

We don't have "pairing" stations so pairs have to pick someone's personal computer. I will admit that being in someone else's "space" is not ideal. Better to be on neutral ground.

People do need privacy at work. Your cubicle (hopefully office) should be a space you can read e-mails, magazines, do whatever alone. Better for a work station where PP is to be done to be somewhere other than your private space.

Bruce
Tuesday, June 03, 2003

If you are doing PP, why have any privacy?  Seems like management would jump on PP as a way to cut costs.  Staff isn't doing anything productive when they're in their private space, so eliminate it.  Not that most places have any anyway.

z
Tuesday, June 03, 2003

Pair Programming is a great way to weed out idiots from an interviewee or employer perspective.

If in either of those roles you ask "what do you think about pair programming" and aren't met with laughter, you know not to employ or be an employee of that person.

do you see the light
Tuesday, June 03, 2003

"If in either of those roles you ask "what do you think about pair programming" and aren't met with laughter, you know not to employ or be an employee of that person. "

What specific data do you have to say that?

mb
Tuesday, June 03, 2003

Actually, there's a true reason for pair programming's inclusion in XP.  You know the phrase, "All publicity is good publicity"?  Well, when coming up with ideas for XP, they realized that it was a Great Religious Issue, like emacs vs. vi.  Programmers would flock to forums and proclaim that they've never used it and can't conceive of doing it.  Spreading the word...

emacs is better, of course
Tuesday, June 03, 2003

I think the basic dichotomy is between those that think 'no new code without pairing' and 'pairing can work'.

Personally I can't understand statements like 'no new code without pairing'.  Did my brain drop out?

What happens when someone's sick?
When they go on holiday?
When there's a meeting does everyone have to go?
And if only one half goes, does the other twiddle his/her thumbs until they get back in order to write new code?

Pairing is fine, it works.

But it didn't come down from Mt Sinai carved in rock.

Simon Lucy
Wednesday, June 04, 2003

>If i am using TDD why would i have errors?
>So i can be just as productive alone using TDD.

I'm doing TDD with single-person programming
right now at work.  I'm finding piles and
piles of errors.  I'm fixing them, but:

1) If I missed a test or two, I'm potentially
missing bugs,
2) With PP, in theory, those errors don't get
created in the first place.  (remember the famous
Steve McConnel error-fault-recovery graph?  The
earlier you find it, the less effort it takes to
fix ...)


regards,

Matt H.
Wednesday, June 04, 2003

[Personally I can't understand statements like 'no new code without pairing'.  Did my brain drop out?]

Possibly.

Personally, I can't understand why normally level headed developers all of the sudden start anticipating stupid behaviour when faced with a new process. Maybe it's our inbred desire to flush out edge cases.

Look, you must have some sort of process where you work now. Does your brain drop out when you use some of the practices included in it? Of course not. Why assume XP and PP are different?

For my part, when we say "no new code without PP" we're saying that any story representing a new feature automatically has a pair of developers (at least) assigned to it. We don't shackle them together. They don't have to get married. Common sense.

If PP makes sense, use it. If it doesn't make sense, don't use it. I would hope that everyone would take that approach with ANY process, not just XP.

Bruce
Wednesday, June 04, 2003

["If in either of those roles you ask "what do you think about pair programming" and aren't met with laughter, you know not to employ or be an employee of that person. "]

Good idea. Base your assumptions on your flawed assumptions. You'll go far in this industry.


To just scoff at a practice without ever trying it or evaluating it yourself is just plain assinine. Yes I just called you an ass.

Ian Stallings
Wednesday, June 04, 2003

"To just scoff at a practice without ever trying it or evaluating it yourself is just plain assinine. Yes I just called you an ass. "

Actually, Ian...He never stated he never tried it or evaluated it. As far as you know, he has been through 2 years of PP and this is his opinion...

This thread is now a complete waste of space.

Idiots Annoy Me
Wednesday, June 04, 2003

"Personally I can't understand statements like 'no new code without pairing'.  Did my brain drop out?

What happens when someone's sick?
[other questions deleted]"

Pair programming isn't a marriage.  It's a high school dance.  You're not locking into the same partner for the duration of the project--you choose a partner when you start working on a story, which is usually significantly less than a day's work.

We don't use pair programming across the board here, but we pull it out as a "pinch hitting" tool when we get to a particularly difficult feature or a nasty bug.  The transition from "pair programming works" to "no new code without pairing" is just XP's metapractice of "take a good idea and turn it up to 11".  Whether or not it works when taken to that level is another question.

Tim Lesher
Wednesday, June 04, 2003

Sorry, next time I'll post something you find more appealing. You know not everything I say has to be insightful or filled with fact. Somethimes I just get annoyed and want to talk smack. If you don't like that well I really don't give a shit.

Ian Stallings
Wednesday, June 04, 2003

"Somethimes I just get annoyed and want to talk smack. If you don't like that well I really don't give a shit. "

Oh well that makes perfect sense. You have a need to make unfounded, idiotic assumptions and call them fact all the while verbally "smacking" people around.

High school was tough for you, wasn't it?

Idiots still annoy me
Wednesday, June 04, 2003

Inflexibility is the worst course, regardless of how good that course is.

I haven't said Pair Programming is wrong or unnatural.

Simon Lucy
Wednesday, June 04, 2003

Gustavo: "At an ill-conceived.com that I was working at, the new boss read a book on XP, and decided that clearly everyone should be pair programming all the time."

Arg. Its these freaks that have probably inspired so much of the backlash against PP. I am certainly willing to try it, a friend had some success with it, but I can see how it is very difficult to make it work. Many of the advantages of much of XP seem to have a very narrow range of applicability. Very short timeframes, low TLOC. Its just so damn hard to get some good studies on it.

I think there is something up on the foruse website http://www.foruse.com but couldn't find the link.

Richard
Wednesday, June 04, 2003

[Oh well that makes perfect sense. You have a need to make unfounded, idiotic assumptions and call them fact all the while verbally "smacking" people around.

High school was tough for you, wasn't it?]

You know what, yo u are correct. Deep down I'm an asshole. Everyone seems ok with it but you take exception. Oh well.

Ian Stallings
Wednesday, June 04, 2003

Pair Programming is Hard

Look, for most experienced programmers, pair programming is very difficult.  It requires that one must engage ones people skills at a time when one is not used to doing so.  One must change ones way of working.  And finally, it's intense.  I'd come out of 8 hour pair sessions mentally drained, what would normally take 12-14 hours alone.  Part of it was because I wasn't used to it and was expending effort being a nice pair, but part of it was because you can't/don't take the mental breaks that you normally do while programming.

Is the pain worth it?  Definitely.  But you have to want it.  If you're doing it just because your boss says you have to follow the trend of the day, it's going to fail miserably.

Bryan Larsen
Thursday, June 05, 2003

*  Recent Topics

*  Fog Creek Home