Buddy Programming

The company I work for didn't like the idea of PairProgramming since it meant "half their expensive workstations would be unused". BuddyProgramming is a theoretical compromise: its still one-man-one-workstation-one-task, but the idea is you're located next to someone who is working on a similar area of the project. Hence you can share ideas, design together, brainstorm etc.

A half-assed solution? Discuss. -- JayBell

I think this would be more ideal than sharing a workstation in PairProgramming. Ideally the two are next to each other and are accessing a shared code repository. Let the one with the better design plan (if nothing else, the creator of the project) start with test writing (write the first tests that will fail), committing the changes, and then the other starts writing code to get the tests to pass, while the original continues writing more tests until his/her design scope peters out. Then they switch roles.

How long does it take for your "buddy" to tune in to what you are doing? How many times per day do you require the help of your "buddy"? How long do you try to solve a problem alone before asking your "buddy" for help?

Ten years ago, when I was working on a product for a Japanese company, one of the clients came out for a site visit. He remarked that where I had three boxes on my desk (workstation, PC, and ICE), his company would have one box for three people.

In the States, at least, I would expect wetware to be far more limited a resource than hardware.

"half their expensive workstations would be unused"

I see this lots of other places also. We spent <some large amount of money> on <some tool>., therefore we must use <some tool> as much as possible.

The SunkCost concept helps fight this fallacy.