Fog Creek Software
Discussion Board




Pairing

They are going to start pairing where I work. This won't include me, at least for now, because my group is just me and one other guy. There are 6 programmers in the other group, working on a project that has been taking forever, and the managers decided to try extreme programming to see if that would get the project moving.
I know the subject has been discussed here before, but not recently. I can understand how pair programming would help communication, but I can't imagine working that way all or most of the time. I would like to have more communication and code reviews, and to work together with others now and then. But it seems to me that isolation is absolutely necessary, at least part of the time, for getting into a creative and focused state of mind.
As I said, this new policy will not affect me now, but who knows what will happen later. I think of it as two artists trying to paint on the same canvas. Every decision would have to involve a discussion. What would happen to that sense of freedom you get from doing things your own way? And wouldn't the person with the stronger personality get to make most of the decisions, even if his ideas are not necessarily the best?
I would like the chance to work with a really great programmer, for a while, because it probably is a good way to learn. But can't you learn as much from just reading their code?
Working together and communicating can be very helpful, I agree. But I think I would really hate pair programming, if forced to do it all the time.

The Real PC
Friday, May 30, 2003

Here's what I think of it.  Pairing with someone I feel I can't communicate with is bad.  Pairing while disliking my job is fairly bad, but livable.  I definitely do not want to pair 40 hrs/wk, I think people do 10 hrs/wk, though I never kept track.  The rest of the time, you're thinking of ideas, taking care of emails 'n stuff, maybe exploratory coding...

I've always colored around the lines, sometimes we'd just diverge and the other guy takes care of different things.  I don't think you're "supposed to" check in code not written as a pair, but who's to say what's natural.  I'd advise not to treat it as too special, but as an interesting way to do what you do...  If you try it for some weeks and it isn't working, at least be able to say specifically why.

Oh, try to get someone who types about as well as you.

greggae
Friday, May 30, 2003

Read this thread:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=45793&ixReplies=31

Which, despite Bill's fairly focused question, was (I think) a pretty nice "catch-all" on XP.

My $.02: Recipe for failure. XP should be a measured decision agreed to by all involved from the beginning of a project. It takes solid, firm leadership and dedication by the coders. It is not a panacea to be thrown at just any coding problem.

I'll bet you that productivity will go *down* and absenteeism might actually increase if this goes on long enough.

To solve the problem, the first important step is to identify the problem. WHY is the project behind? Was the schedule overly optimistic? Is progress being made, just not fast enough? Are the coders in over their heads? Are they working with tools not suited to the job? Is the work environment detrimental to progress? Are the coders spending all day surfing Monster and sending out resumes?

Just a hint: XP won't help with any of those scenarios. :)

Philo

Philo
Friday, May 30, 2003

Pair programming is the single most stupid idea in the history of software development.  I am frankly astounded that ANYBODY takes this idea seriously at all.

But looking on the bright side, the more idiots that screw up projects with trendy non-methodologies, the less competition there is for competent people.

the truth
Friday, May 30, 2003

Please keep in mind that:

Pair programming != XP.

It's not even the most important part.
(TDD and planning game are the most important parts of XP, probably)

raindog
Friday, May 30, 2003

Keep an open mind.  Unless you get paired with Bob N.

Nat Ersoz
Friday, May 30, 2003

I've done a good bit of pair programming, and even advocated it to some extent at my work.  Like all undertakings, your mileage may (will!) vary.  It's not a panacea; nor is it necessarily the next apocalypse.

My feeling is that pair programming works best when people are unevenly matched (eg, one is less experienced than the other).  Particularly, it works best when you're trying to close the gap between new hires and experienced developers in learning a codebase.  And like with most team endeavors, there really has to be a natural leader and not two strong personalities fighting it out (eg, the "two artists" scenario).

That's not to say that the strongest personality always wins.  It depends, frankly, on whether that person is a jerk who's unwilling to listen or give up control occasionally.  But that doesn't constitute a leader in any case, just the typical prima donna who doesn't do terribly well on his own, anyway.

Really, it boils down to what Peopleware refers to as the jelling of teams.  Pair programming is nice because it's a mini-team; a team of two, if you will, and is easier to jell.  If you have the luck of experiencing the right dynamics, then it will be a wonderful collaborative experience, and your creativity will complement your partner's.  This does happen; I've certainly experienced it myself.  But it's unfortunately difficult to predict whether it will.

That said, I definitely agree that 'round-the-clock pairing is a nuisance.  Programmers need downtime, and that's something continual pair proramming doesn't accomodate very well.  When you are in the pair situation, try your best to push for some reprieve--even if it means colluding with your partner against management's wishes. :)

smkr4
Saturday, May 31, 2003

smkr4 -
"Pairing works best when the two programmers are different skill levels"?

Doesn't that simply become a master/apprentice situation? I mean, it's viable in its own light, but there the goal is to bring the junior person up to speed quickly (as you said), while pairing is meant to feed off the crosstalk between two people of comparable talent.

I would *hate* to be under a deadline crunch and have someone with little experience working with me - I'd probably make him QA or give him cleanup work or something...

Philo

Philo
Saturday, May 31, 2003

Philo, have you ever tried pair programming? :)

raindog
Saturday, May 31, 2003

This project that's taking forever is not my project, and I only have a vague idea what it's about. From what I've heard, the problem is that they did not communicate well with the future users during the design stage. The (former) project manager is completely non-technical, which did not help communication. The process was not iterative -- they did not start with a relatively simple prototype that could be used right away, and which would gradually evolve into a complex system. The concepts of iterative design and communication with users (which should be obvious to everyone) come from Extreme Programming.
I don't know why they're trying pair programming also, except that some consultants came in and recommended all the Extreme stuff, not just what makes sense. The boss is skeptical but willing to try it out.
Maybe it's a technique for weeding out absolutely useless coders. The boss said anyone who is not able to work this way will no longer be involved in Project Dud.
All my projects, since I have worked there (2 years) have been one-person projects. I'm in the R&D group (which now includes only 2 of us). They are cutting back on developing new products, temporarily, to see if Project Dud can ever be finished. They took the most experienced guy from my group, and left just 2 of us. The other remaining guy spends all his time maintaining an important system. So I am the only R&D person left, really. My manager is now also the project manager for Project Dud (because he is a good manager who gets things done). I expect I'll be left alone to do whatever I want for the next 6 months.

The Real PC
Saturday, May 31, 2003

What's the definition of pairing here?
First, if your management jumped on paired programming because they have read alot about it lately then you'll soon switch to a new methodology. Second, if paired programming means sitting next to someone in front of one monitor/keyboard working on the same piece of code then I don't see any benefits. The stronger personality will do everything.

J.
Saturday, May 31, 2003

They decided to try all the Extreme Programming ideas, which includes pair programming.
Iterative design and communication with users is part of Extreme Programming. However, these ideas came long before and were practiced by many developers (including me) before there was anything called Extreme Programming. These ideas make sense; pair programming does not make sense (to me).
Pair programming goes along with the whole Extreme package of ideas, unfortunately.
Fortunately, I will not be included; at least not now.

The Real PC
Saturday, May 31, 2003

"Maybe it's a technique for weeding out absolutely useless coders. The boss said anyone who is not able to work this way will no longer be involved in Project Dud."

OMG. What an awesome recipe for randomly firing people, including some of your best coders. Might as well say "everyone has to wear happy clown feet to the office. Anyone who doesn't like it is gone"

Philo

Philo
Saturday, May 31, 2003

You should get more than one terminal, since what happens if the driver's crusing and you see a speedbump coming up that requires a small bit of research?  You get to look at a map while the other guy drives.

Hasn't anyone ever coded with someone for fun, or more generally worked with someone to accomplish a task that theoretically could have been done alone?  Just keep it natural, and see if you can make it work.

greg
Saturday, May 31, 2003

Pair Programming is, like everything else in life, what you make of it.

I can't fathom working that way all day every day.  But I can't fathom never working that way, either.

Personal experience has revealed Pair Programming to be useful when writing complicated procedures.  The mix of close focus and wide focus may not speed up the actual coding process, but it certainly reduces rework, which speeds up the project as a whole.

Of course, this is just my experience, and I'm a determined fellow.  A programmer with a bad attitude who lacks the determination to make PP work isn't going to get anything out of it under any circumstances.

Norrick
Saturday, May 31, 2003

[OMG. What an awesome recipe for randomly firing people]

They don't fire anyone at this place. Useless people are promoted to positions where you don't have to do anything.
If Bob N. doesn't do well with extreme programming, I guess they would take him off Project Dud and promote him to Head Websurfer.

The Real PC
Saturday, May 31, 2003

Pair programming is for people who've never done any genuinely good development of their own. This applies both to the managers who introduce it, and the faddists who become enamoured of it.

Not bored
Saturday, May 31, 2003

I never woulda believed it, but there is more than 1 person in the world who's nickname is Bob N.

I knew Bob N. (different instance) back in another day.  And wouldntcha know it, all the way out in Seattle, I run into another guy who knew the same Bob N. 1/2 a continent away.

Small minds, amused by simple things...

Nat Ersoz
Sunday, June 01, 2003

*  Recent Topics

*  Fog Creek Home