If you haven't used Pair Programming (PP) before but want to introduce it, there are two additional books you should read for background. They aren't textbooks for your class, but put PP into context. Extreme Programming Explained gives the complete context of PP in the agile development process. Pair Programming is one of the "small scale" practices of Agile Development - a personal practice, that is used in most agile methodologies.
The second book Pair Programming Illuminated focuses more on PP itself.
Since students may do much of their work outside your view, they need to be convinced that it gives them something or they won't use it. The alternatives seem too enticing to them (e.g. splitting the work...). So the classroom demo suggested here (points 3 and 4) is probably necessary: Techniques for encouraging pair programming.
The problem is that they already have programming habits and they will fall back on those in a pinch unless they see a compelling reason to do something different and develop new habits. The classroom demo can help with that. But you have to play navigator yourself, not just driver, in your demo.
The wisdom of the profession on PP is that the driver takes a microscopic view of the project at hand. If the navigator is behaving correctly he/she will take a broader view, thinking about how what the driver is doing fits into the whole of the app being developed. When you work alone you only get the micro view, which often enough leads you astray.
The navigator is not just an after the fact reviewer, but an active participant. That takes practice. This is the key to making PP productive. You have two minds on the problem and each has a slightly different perspective.
Another advantage is that single programmers often get stuck and have to think for a while about how to proceed. But two programmers seldom get stuck at exactly the same point. That is the time to switch roles. The navigator notices a change in the pace and, perhaps, takes over the driver role for a while.
I have a picture in my head of 10 programmers, each working alone in a cubicle, and each stuck on something, making no progress, but the person in the next cubicle having the key to continue.
Another good practice, if you are always using test first programming (TDD = Test Driven Development) is that one person writes a test, which fails. The other person builds enough of the app to make that test pass and then writes the next (failing) test. The first person takes over to make that test pass, etc. Back and Forth. Clockwork.
To understand when and why the driver and navigator roles should switch, think about what a solo programmer does quite naturally. You are programming and have been for a while. You are in the grove. Things are flowing. You are focused like a laser on your work. The solutions are coming naturally. And then... suddenly you hit an obstacle. The next thing isn't obvious. At that point, you naturally widen your focus and look at the wider picture. You eventually "get it" and move back in to continue. Or, perhaps, you take a break.
On the other hand. Consider what is natural for someone looking over your shoulder as you work, making occasional comments on things like naming, or structure. Perhaps reminding you of some method or tool you might employ rather than building something new. They are taking a wider view since they don't have responsibility for the progress. And then, suddenly, they notice a change in the pitch. You aren't making progress and seem puzzled. At that moment, their instinct is to focus more closely on what you are doing to try to resolve the issue.
So, one person widens focus and the other tightens it. That is generally the moment to swap roles as the role is determined by this level of focus.
If you try to switch roles by some arbitrary means, such as time, you will likely lose the advantage of the "dual focus" view of the project. The most likely outcome is either (a) the navigator becomes disengaged altogether or (b) both take the laser view, losing the broader, overall, view of the program.
