Flutterby™! : Team Programming 2001-05-25 18:06:26+00

Team Programming

2001-05-25 18:06:26+00 by Dan Lyke 9 comments

Phil and I have been experimenting with "team programming", one of us typing, the other looking on. It takes a strong ego, because there's always someone else there to see mistakes, but yesterday and today we've developed a decent system that we're fairly sure both of us understand. I'm not sure that this is the way to develop all code, but when fleshing out larger frameworks that will be filled in with detail code later there's a lot to be said for it, especially when one programmer is a strong coder, but is unfamiliar with a particular environment's quirks.

After we'd white-boarded out a clear vision of what we were trying to accomplish, we realized that it would be hard to split the first parts into any sort of separately implementable systems. So we sat down at his computer, him typing, both of us talking about what the particular piece of code that he was entering was supposed to do.

Obviously there were the usual number of silly gaffes and stupid mistakes, but at the end of yesterday we both felt like we'd turned out a substantial amount of code that we were very confident in, and more than just knowing it would run correctly also felt that it didn't have those little "gotcha" assumptions that would bite one down the road.

There are some assumptions because of the nature of existing data that I feel will be a problem, but since we were implementing on top of that infrastructure we couldn't much change it, and I think because we've both hashed out the issues involved thoroughly it'll be easier to fix things when we have to restructure that code.

Is it more productive than coding alone? I'm not sure, but I know that I feel much more confident about that code than about code that either of us writes in isolation.

This style of writing code is a primary aspect of Extreme Programming (XP). It looks like a promising methodology. It's just really hard to convince management that two programmers working at one computer on one thing can really be more productive that two programmers working at two computers on two things. But my experience has been that team coding can be more productive given the overall life cycle of the code. For instance, you don't have to explain to Phil how any of that code works and there are two people in the world capable of working on it in a timely fashion. Generally in single-coder mode you end up with large volumes of code that only the original author can really comprehend enough to modify. Especially if that author has a really strong grasp of the language and tends to use the more technical aspects to it's fullest extent.

Pair programming really starts kicking ass when you adopt one of the other XP practices: write your test cases first. For one, it gets them done. But it's also a confidence doubler. There's nothing quite like being able to push a button and run a complete regressions suite immediately after you've cranked out new functionality. If there are problems, your mental context is still fresh. And once all of the tests run successfuly, you can walk away from the day without that nagging feeling that you may have broken something somewhere else.

This sounds interesting. It sounds like you've come up with a better way to take advantage of two minds working on one problem than the usual "split the work in half" symmetric-multiprocessor strategy. It is also a step toward removing the ego from the code.

I don't think I'd be able to do it, because my ability to type accurately falls apart and my recall of relevant details disappears when someone looks over my shoulder.

dws: do you really save as much debugging time with those test cases as you spend writing them? It seems to me that a test harness capable of catching a meaningful fraction of the bugs in that module takes more design work than writing the module itself. Unless someone spends more time debugging than developing, they're going to lose out.

I don't mean to be a cranky skeptic - I just can't see how it's meant to add up.

If you have management that can

tell the difference between effort and effectiveness, then I want a job. And I don't mean that to sound as snide as it comes off, I have trouble doing that on my own work, and will often substitute time in front of the screen when I feel like I need

to be productive but don't know where to turn next.

I'd gotten pretty burned out on reading about software engineering so I've been ignoring the whole extreme programming thing, but it sounds like even if these are techniques that I'm already using having a shared vocabulary would be useful; can anyone recommend the best book to read?

Well, there are three ou there now: Extreme Progamming Explained by Kent Beck (the first), Extreme Programming Installed (how to implement the principles), and Planning Extreme Programming (a whole book on the planning phase). They are all quick enjoyable reads. I would guess that the first two would be a good place to start. The authors of these books are all hard core XP weenies and they made sure that there wasn't too much content overlap.

I read the Kent Beck book when it first came out. It was enlightening, to say the least. Unfortunately, I haven't had a chance to work in a shop where XP was even a possibility.