Quality starts and a save: Starter-reliever development

I’m not a huge fan of pair programming. Mainly, that whole two-people-sitting-at-a-desk thing.

It requires a bit too much cohesiveness and etiquette with your fellow developer that I simply don’t have. It also compromises each developer’s unique programming style. For instance, I tend to program incredibly loose, at first, and refactor my mess very frequently. Someone else might do just the opposite. My way works better…for me. If I had to work in tandem with someone that didn’t work my way, we’d both be incredibly frustrated.

A better methodology that I’ve been using is what I’ll call Starter-Reliever development. It really works much like a pitching staff in a baseball game, taking into account the natural “fatigue” that occurs during a development cycle. Mustafa and I have used this technique pretty successfully on our work with X2O (Mustafa as a starter, myself as a reliever).

The starter and reliever start a programming session by deciding two things:

  1. What are we building
  2. How are we doing it architecturally

It’s critical that both starter and reliever understand exactly how the architecture will pan out.

The starter is responsible for writing the majority of the code and sticking to the plan. Should he diverge from the plan (because he found a better technique or a flaw in the original plan), he just needs to relay to the reliever exactly what’s happening. Starters have to be bull-headed, take risks, and fight through obstacles. They also must understand the big picture just as much as the reliever.

Starters, doing the bulk of the programming, will eventually lose focus and energy. They decide when they’re done programming and need to be taken out of the game. Like a pitcher qualifying for a win, these prerequisites must be met before they can take themselves out:

  1. All the major tasks of the programming session are completed and functional
  2. Any loose ends to minor tasks must be relayed to the reliever

The relievers job is to finish the game. He must be incredibly attentive to detail – a bit of obsessive-compulsiveness is not a bad thing. Since he’s fresh into the game, he’s got the stamina to finish up minor tasks (usually the mundane ones). The reliever also spots simple opportunities for refactoring to keep the code in good shape. Ultimately, the reliever picks the starter’s last few innings up and saves the game. At the end of a reliever’s stint, the application should be 100% complete.

I far prefer this approach for a couple reasons. First, it lets two talented programmers not get in each other’s way or compromise their development habits for another. Second, it ensures that a fresh developer is working on the application at all times. In pair programming, you’re likely to have both the “driver” and “observer” wear out at the same times.

I don’t think starter-reliever programming works for everyone. But, if you can find the right qualities in a quality starter and a shut-down reliever, there’s a game out there to be won.