HEWLETT-PACKARD and IBM used to have an annual boat race – or so the apocryphal story goes. For years in a row, HP beat IBM by miles. Eventually, IBM’s senior management couldn’t take any more of it.
“Enough of this public embarrassment” they said. “Let’s put together a committee to get to the bottom of it. Why does our team infallibly lose to HP’s?”
So a committee was formed, paid well, and sent away on a corporate retreat to ponder this pernicious problem. Eventually, after six months of painstaking analysis over many games of golf, the committee returned with a recommendation.
“We know why our team always loses to HP.” They said. “HP has one person steering the boat and eleven persons rowing. But we have one person rowing and eleven persons steering.”
Impressed at this penetrating analysis by its committee, IBM sent them away for another six months to come up with a solution, which they did. When they returned, the spokesperson for the committee stood up and said. “We’d win the race if the person rowing the boat rows harder.”
And so it is with group programming. Williams and Kessler  talk about group programming as a natural extension to pair programming (p.84). Often I have a class with an odd number of students and I cannot successfully pair them all off. In such cases, and in situations where pairs specifically request it, I have tried to allow the formation of groups with more than two programmers. However, I have to be careful that I don’t end up with teams in which many programmers navigate and one drives. Even with my timed role rotation strategy, such a situation simply won’t work. At best, the teams with multiple navigators would end up completing their projects far too slowly and we’d have nothing to reflect upon and discuss by the end of class. Thus, I found the best compromise was reached with the following arrangement, which seems to work beautifully. The ground rules, which I typically explain to the students a few times during the first few lectures are:
- No more than three students per group
- Still only one keyboard and screen per group
- Student A is the navigator – Calls out the code to be typed in.
- Student B is the facilitator – Understands what the navigator is calling out and can interject with questions like “Why?”. This person cannot make suggestions, or change the design decisions of the navigator
- Student C is the driver. Simply types in the code called by the navigator, which was possibly modified as a result of interjections by the facilitator.
- Upon rotation, roles are switched thus: A assumes B’s role. B assumes C’s role and C assumes A’s role. The navigator must hit the ground running.
- It’s important that design decisions once made are committed to even though the person taking over the navigator role may not necessarily want to solve the problem the particular way it’s being done. This maximizes the group’s chance of completing their task first to win the race.
- The end-of-class prize of EC Bux for the first team to complete is adjusted to account for increased group size.
 Laurie Williams and Robert Kessler. 2002. Pair Programming Illuminated. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA., p.84