All the Perl that's Practical to Extract and Report

Pair programming

TorgoX on 2003-04-08T05:45:04

Dear Log,

In a book on XP, I saw a discussion of pair programming -- i.e., two people at one keyboard. The mere idea is giving me a claustrophobic fit. I'd sooner abandon programming altogether than have to code with another hyoomon in the room, much less one watching me code, or expecting me to watch him code.

Depends

Dom2 on 2003-04-08T08:07:59

I mean you're a super CPAN magnet, with vast swathes of lovely code behind you. Stuff in Perl core, too. But for 90% of the rest of us that aren't so hot, it's a good idea. It tends to catch the really silly mistakes before the file even hits the disk. And the interface design ones too.

-Dom

Re:Depends

TorgoX on 2003-04-08T09:39:46

It's not really a matter of skill -- it's just the experience of sitting next to somebody and sharing a machine with them for hours at a time. It just crowds my space. I'm probably just being neurotic this way -- but I think a lot of programmers feel the same way.

"I VANT TO BE ALOOOOONE."

We are all Garbo now.

Re:Depends

chromatic on 2003-04-08T09:46:36

Yeah, a lot of programmers are scared to death of things they've never done before.

Re:Depends

darobin on 2003-04-08T13:56:18

I'm not scared, I've done it and I hate it. I think in order for it to work one needs to be a much better multitasker than I am (eg I can't be on the phone and have someone nearby talking to me at the same time, as most humans can -- I'll lose track of both conversations). I can't be 100% concentrated on code and interact with someone at the same time. When I tried I made far more (stupid) mistakes than I usually do, and worse: when my pair pointed them out I failed to see them because I was focussed on listening to him and couldn't read the code. When he coded, it took two minutes before I started thinking about the next problem and lost track of what he was doing.

No silver bullet and all that...

Re:Depends

chromatic on 2003-04-08T17:47:48

That's fine; it doesn't work for some people. The University of Utah study showed only a 90% or higher uptake rate for pair programming. Of course, these were students and they did it consistently, for an assignment, for a couple of weeks.

Take my comments with a grain of salt, though. The first programming class I ever took, back in the 80s, had too few computers and I had to pair. It didn't go well, partly because we were so very young and partly because we had no idea what we were doing.

Re:Depends

TorgoX on 2003-04-08T20:00:58

Numbers are fun for pretending everyone's the same.

Re:Depends

pudge on 2003-04-10T12:13:07

I agree with TorgoX, and it is entirely, completely, absolutely unrelated to whether or not I have done it before.

The two coders I work with the most are halfway across the country, and all the way across the country. I've not seen either one in close to two years. We work on IRC together, pointing out line numbers, pasting in code, emailing diffs. We keep the code in CVS and I we look over each other's changes. I much prefer that. Perhaps some things slip through the cracks that wouldn't in pair programming, but there are things more important than that, such as sanity and longevity.

Re:Depends

Dom2 on 2003-04-08T10:26:14

Heh, another reason it's a good thing. It encourages you to get up and go away from the computer more often. :-)

-Dom

XP Without trying..

Beatnik on 2003-04-08T09:53:42

2 Weeks ago, in the middle of a development cycle, I found myself waiting for something to do. My less experienced cow-orker took the larger piece of the puzzle and I finished mine after some hours. Since I couldn't continue with anything else, I started reviewing his code and we actually started working together on his part of the code. We argued a lot more than during our planning process but we always worked it out. I didn't really look into XP all that much but when it comes to working in a team, I learned quite a bit so far.

Pair Programming vs. Review

ziggy on 2003-04-08T12:15:15

The core idea behind XP is anything that is worth doing is worth doing continuously. And if you're going to do something continuously, then it must be cheap. Testing is good, so make testing a cheap part of the activity -- write tests first and run the complete test suite at every checkin.

In this context, pair programming is nothing more than cheap, constant review. I've seen a development shop where a team has been working together on a project for months adapt some of the XP methodologies to suit local conditions. Going from a traditional development environment to full bore XP is a certain recipe for failure. Their "customization" of pair programming was to institute a policy of review during checkins.

I know of one other environment where "pair programming" meant programming head-to-head with a peer using two computers back to back. This aided the other goal of pair programming, constant cheap communication. In this instance, the programmers could just casually say, "What do you need a select method to return?" or other simple question to hammer out an interface while in development.

Pair programming is good. Just don't buy into the definition that there's exactly one way to pair program. :-)

Re:Pair Programming vs. Review

sungo on 2003-04-08T14:59:25

isnt this what company irc/im and cvs commit mail is for? :) i actually prefer the irc route because then, no matter what their location, i can have the whole team in a "room". so when i ask questions like "JESUS CHRIST WHO THOUGHT THIS WAS A GOOD IDEA?" the team can benefit from the discussion and not just the pair.

and yes, i agree with torgox. the few times people have tried to pair with me (sitting next to me, watching, and commenting) were disasterous. i hate being watchced and i hate discussing and defending every little line of code or debug print i add.

Re:Pair Programming vs. Review

chromatic on 2003-04-08T17:51:56

Pair programming in XP is more than just code review. It's also a design session. Where the planning game does a little design in the large, it's the test-driven cycle that does planning in the small. As you're baby-stepping your way toward the goal with testing, you're also designing with your tests and refactorings.

Then there's the "Hey, we just added code without a failing test! Oops!" peer pressure. It's hard to overestimate that.

Re:Pair Programming vs. Review

pudge on 2003-04-10T12:14:12

Then there's the "Hey, we just added code without a failing test! Oops!" peer pressure. It's hard to overestimate that.

I do that in IRC and on the mailing list.

Not for everyone

Elian on 2003-04-08T15:50:35

Like so many other things, this just isn't for everyone. If it's the claustrophobia (I personally hate having people hover over me) then there's stuff like Hydra for OS X, which is really cool.

Pair Programming and Temperment

dws on 2003-04-08T17:32:25

Pair Programming isn't for everyone. Some personality types don't take to it easily, and some personality combinations make for bad experiences. There are a couple of specific people who I can not/will not pair with unless I have a titanium crowbar within reach. And there are personality types I find difficult to work with (e.g., people who do all of their thinking out loud, without the benefit of an internal censor to screen out nonesense). But as I've paired with more people, it becomes easier. Even if I'm mostly teaching my partner, there's usually something to learn (like some small keyboard shortcut that makes life just a little bit easier, or an insight into why certain ways I approach problems go over the heads of people with less experience). Pairing with more experienced people has almost always been a lot of fun, and meshes with my preferred mode of learning.

I do miss closing a door and putting on my favorite coding music (Gregorian Chants), but I can still do that at home.

Pairing may not be for you, but give it a try a few times before rejecting it entirely.

Re:Pair Programming and Temperment

pudge on 2003-04-10T12:14:54

And what if the person you are paired with likes a different kind of porn than you?

Re:Pair Programming and Temperment

dws on 2003-04-10T16:22:30

It's a chance to expand your horizons, silly.

Re:Pair Programming and Temperment

nicholas on 2003-04-14T16:14:35

unless I have a titanium crowbar within reach

They're not very good - too light to have a decent amount of momentum in the swing. I've decided that I prefer steel crowbars, about 30 inches being my favourite length.

And you think I'm joking...

more is less

hfb on 2003-04-09T06:30:15

"[crash programs] fail because they are based on the theory that, with nine women pregnant, you can get a baby a month." -- Wernher von Braun

Having 2 or more people working in close proximity on the same problem usually contributes to overengineering of a problem which, in turn, slows down the delivery time and doesn't really contribute to the overall quality. This touchy feely fad will die out once someone figures out that it's not a substitute for a sharp code wrangler who knows how to herd cats and knows the team well enough to have each focus on the parts of the project they can contribute to the best. Two mediocre brains do not make one good one.

Re:more is less

pdcawley on 2003-04-09T07:09:56

So don't hire mediocre brains.

Re:more is less

hfb on 2003-04-09T07:22:42

I don't know very many un-mediocre brains who want company in their cube and competition for their keyboard.

I'm in a pair now...

clintp on 2003-04-09T16:46:03

Our shop started pairing a couple of months ago. A lot of the enjoyment comes from who's your partner. Last month I had a 15-year veteran of this code, very intense, etc.. and we accomplished a lot. Today I'm with a 4-year novice who's a lot more laid back and I'm not accomplishing as much but I feel better about life.

Once in a while though I do get a problem where I scurry back to my office and brain on it a bit by myself. Then go back to my partner and we start up again. Sometimes that "go away and think" is a lot better than pair thinking.

Re:I'm in a pair now...

pudge on 2003-04-10T12:16:36

Ha ha only serious: some of my best thinking, and best programming, happens on the toilet. No way will I do pair programming THERE.