Paired programming with an odd number of students I have only lately started allowing (and encouraging!) paired programming, and it is going very well.  The kids enjoy it, and they appear to be learning the material with less pain.  Not everyone has done it yet, however.

This is where I am beginning to sense trouble. I have a difficult major programming lab coming up soon, and my students are psyched to work together on it.  I know that many more of them will want to try pairing, but I worry about odd numbers, and I'm not sure how to handle three students who desire to work together without destroying the benefits that the model can provide.  Is there any way to extend the model of driver and navigator to a trio?

My current intention is for each group to create the same product, with no "splitting" of the work.  One monitor, two students.  Driver and navigator.  These are good and responsible kids, and they can usually find quite productive groupings on their own, though I have no problem stepping in to assist in this if I see things headed in a poor direction.
An extension I've come to appreciate is one where you have a "driver", "observer/navigator" and "keeper". 

This last role might be considerably more difficult, depending on the lab. The idea is to have someone who keeps track of the design. This means that at the start of the lab, the students should all (or just those who start as keepers) dedicate a bit of time to read up online about design patterns in the language they are using. It's important "not to delve too deep". Just a general idea of what "design patterns" means.

Then they begin working. Two out of the three work in usual pair-programming workflow. The third keeps in mind the design of the program. As with regular pair-programming, the students should switch roles every now and then. In the case of a trio, they should obviously cycle.

If not all students in the lab are in trios, then an additional for the navigator is to remember design patterns. It should be made clear that it's not their primary task, but that it would definitely help with debugging and maintaining the code.

The added bonus of this extension of pair programming is that students are exposed to design patterns. Seeing as they can sometimes be a complicated matter, starting to tackle them is better done sooner than later.

I have found this solution quite useful in labs about subjects in OOP (the more complex the system, the more important SOLID principles become).