Collaborative development, pair programming, etc.

re: Collaborative development, pair programming, etc.

Paul — Fri, 03 Feb 2006 19:42:02 GMT

I wrote a rather lengthier reply in my blog to your post (which I think raises some great points): http://www.oobaloo.co.uk/articles/2006/02/01/pair-programming

However, I did have one observation I wanted to make here (albeit a bit more succinctly).

I don't think there's necessarily a direct correlation between intro/extrovertedness and how well the person works in a pair. I think it's more fundamentally down to how they perceive the benefits of pairing, but also how they perceive a kind of fear through working directly with someone else.

I've worked in pairs where the 2 of us have been extremely productive -- moreso than one of us working on our own, we actually got through more work, not just producing better work! However, there have been other times where if one person isn't entirely convinced, it's very difficult to achieve the benefits pairing promotes. For instance, if the navigator of the pair isn't interested, they won't be asking questions, and the driver will just go on whichever route they please.

Although Miral points out there are places that still have excellent communication, I still think nothing beats actually looking at the same code, asking questions of each other "Where are we going with this, what do we actually need to do here, are you sure this is what the customer wanted?" Rather than spending a few hours going somewhere you didn't need to, before asking the room how to do something, only to be asked why you felt you need to do it (fortunately, not something I've had to do! :)).

I think your post was spot on with regards to drivers against it -- I think people either think that they have a greater commitment to throughput, and see that working by themselves they get more done, or, they perceive that their code will be torn to shreds and they'd rather get it out the way and take advantage of a fast-moving codebase that obfuscates responsibilties.

As you say, TDD can still lead to unnecessarily complicated, or poorly designed code -- I've seen so many examples of it recently. Crucially though, it gives you the support necessary to ensure that when you need to clean it up, you can do so safely -- that your code performs to the same original assumptions. Pairing should help both prevent this in the first place, but also improve/encourage the tidying afterwards! Together it's a good combo, and I think that a TDD approach really benefits from pairing.

re: Collaborative development, pair programming, etc.

wpoust — Fri, 03 Feb 2006 05:24:38 GMT

I'm in your camp with all reasons with one important caveat; the chemistry of the pair is critical. If you get the right pair programming together, great things can happen. On the other hand, if the each persons doesn't like each other (even if its because of some personal quirk), you might be better off having a lone introvert. I know that sounds awful but that's my experience. I would be willing to take that one step further and say if you find a pair that works great together, don't split them up.

re: Collaborative development, pair programming, etc.

Miral — Thu, 02 Feb 2006 04:42:37 GMT

I'm an introvert who practices pair programming :)

At least when possible (sometimes it's not possible because management gives us more streams of code to implement than we have pairs available, so we have to do individual work; other times the individual work just makes more sense, depending on the type of work).

When not actually pairing, we're still in a common room, so it's still easy to discuss alternative implementations with someone else, or help someone out with a problem, or overhear them discussing something and offer a suggestion. It works out quite well, though not as good as full pairing.

re: Collaborative development, pair programming, etc.

Andy Tegethoff — Wed, 01 Feb 2006 23:49:36 GMT

I'm no Agile guru, and I've had only limited experience w/ pair programming, but my spider-sense tells me it COULD offer great benefits (not WILL, but COULD) were it instituted in certain kinds of teams.
Pair programming has the potential to be like a code review cubed. It's not even just "code reviewing in real-time" -- having someone tell you you missed a semi-colon, or failed to add a Finally clause.
Pair programming has the potential for both current and future benefits, in that you're avoiding low-level stupid bugs that just tie up dev and test time, spreading knowledge of the particular code being developed w/o having to "train" or brain-dump another developer, and capitalizing on the senior developer's architectural knowledge of the larger system (assuming there is one), all in one move. This assumes you're pairing junior programmers w/ senior programmers, of course.
But many of the "anti-review" reasons listed by Eric have "mirror-images" on the side of the reviewer, and can be summed up by saying that people generally take as little time as possible to perform code reviews. That's been my experience, anyway, from both the reviewer and the reviewee side.
To gain the benefit of pair programming, you need pre-dev design reviews AND post-dev code reviews -- both of which are almost certain to be less thorough/in-depth than you'd get from PP.
Obviously, though, PP will not fit every project/team. It's definitely something to consider, though. Perhaps even in opposition to TDD, since TDD requires infrastructure and methodology changes that PP does not.

re: Collaborative development, pair programming, etc.

Wed, 01 Feb 2006 20:38:17 GMT

agreed with all the points.

Matt - "If you've got developers that use the reasons you listed to skip a code review, then you've got bigger issues..." - none of the points listed by eric for skipping reviews make any one a bad programmer.

They are all real live issues/problems and pair programming is just another methodology for helping out with those problems

re: Collaborative development, pair programming, etc.

Nicholas Paldino [.NET/C# MVP] — Wed, 01 Feb 2006 19:59:29 GMT

I have two reasons I have never engaged in paired programming:

1) I am the only programmer where I work
2) No one can match up to me =)

re: Collaborative development, pair programming, etc.

Matt Thalman — Wed, 01 Feb 2006 16:51:24 GMT

If you've got developers that use the reasons you listed to skip a code review, then you've got bigger issues that pair programming isn't going to help with. That's just sweeping the other problems under the rug. If there are managers that allow code check-ins without reviews, that's an additional problem.

Pair Programming

TheChaseMan's Frenetic SoapBox — Wed, 01 Feb 2006 06:32:43 GMT

re: Collaborative development, pair programming, etc.

Kevin Dente — Wed, 01 Feb 2006 01:35:10 GMT

>But TDD doesn't address code maintainability issues - you can still write overly
>grandiose and poorly factored code using TDD.

While TDD can't prevent this entirely (nothing can), it can certainly help. TDD emphasizes YAGNI, which steers you away from overly complex designs. It also emphasizes refactoring, which helps improve the understandability and maintainability of the code.