Collaborative development, pair programming, etc.
There have been some interesting discussion on our internal “agile” alias around pair programming, with some advocates and some skeptics.
I wrote something in response to one of the skeptical posters, who (to paraphrase badly and perhaps miss his point) said that he was an introvert and preferred to work alone. Not that I’m advocating forcing something like pair programming on anybody.
Here’s what I wrote, slightly edited to protect the innocent.
*****
The introvert/extrovert concern is an interesting one. I like to be left alone at times, and I’m also a big fan of flow state.
But I’m also pushing for us to *experiment with* pair programming in our next cycle. Why?
Well, I’ve been on a lot of projects in my career, and I see the same bad things happening over and over again. Code reviews that don’t happen. Important components that one or fewer people on the team understand. Overly grandiose architectures. Re-inventing the wheel. Solutions looking for problems. Bad bugs that are really expensive.
Who is at fault? Well, we are.
For example:
You’ve just finished adding a new feature, and to do so you had to do a bit of re-architecting to fit it in. Do you ask one of your co-workers to review what you’ve done before you check it in?
Reasons you get the review
-
It’s the right thing to do
Reasons you skip the review
-
You’re an introvert. Given the choice between personal interaction and working on something new, you usually choose something new.
-
Your co-worker is also an introvert.
- Nobody really understands your code because you’re the only one who works on it, so the review may not give useful feedback
-
You have to get up, leave your office, find the person, and bring them back. Lots of time, and they may not be there.
-
You get evaluated on the features you produce and don’t feel review pain because of the bugs in your code.
-
It’s early/late, and you’re by yourself
-
You don’t want people to say bad things about your code.
There are a lot of factors pushing you to do the wrong thing, so it’s not surprising that the right thing rarely happens.
So what about TDD? Well, I think TDD is a great way to get code that has fewer bugs in it, and I don’t underestimate the value in that. But TDD doesn’t address code maintainability issues – you can still write overly grandiose and poorly factored code using TDD. You can still write code that is inconsistent with code elsewhere in the project, or using the wrong library. You can still spend hours trying to figure out something where the group knowledge could have solved it in 5 minutes. And – as I am chagrined to admit – I can still write code that should be under TDD but isn’t because it wasn’t convenient.
I don’t think that collaborative development – by which I mean anything from co-location in a big room to pairing – is a silver bullet that is going to solve all these. But I think that it can make a pretty big dent. And as a company, I think we have to figure out a way to stop producing big legacy codebases that nobody wants to work on.
>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.
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.
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 =)
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
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.
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.
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.
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.