Allowing students to work cooperatively on a computer, and retain access to their work I like pupils to work in pairs, as they learn quicker this way, and need teacher help less often.

However, there are problems, when working together on a computer:


Free loaders. For this, I give them two roles: Driver and Navigator. The Driver controls the computer, the Navigator does most of the thinking, and tells the Driver what to do. They then switch role often. I manage this by walking around.
Access to previous work, when the partner is not present. Because pupils have to log in, and use a single account. There is a problem if the account holder is not present (ill), or if I want to re-pair students.


Has any one any experience with this 2nd point, and do you have any solutions?



I am mostly looking for non-technical solutions. I will add a technical solution.

Edit: I am not only asking about programming. There may be other work on the computer.
Actually, in true pair-programming no one works (or at least modifies any code) unless the partner is present. This is an important rule as I've seen really bad things happen when one member of a pair (or team) thinks he/she "gets it" and doesn't. I've had to spend half a day backing out "improvements" that were really misunderstandings by the perpetrator. People are not, however, forbidden to think about the project when alone - which would be foolish. To ease the offline thinking, pairs can be encouraged to simply email the existing code to both members so they have a basis for their deliberations. Printing it is even better, as it can be marked up on the bus, etc. 

To solve the other issues, you could create meta-accounts for the pairs in which pair members know the credentials and change them when pairs are reassigned. Using personal accounts for group work is probably a mistake. 

One way to manage exchange of ideas and peer-teaching in such a situation is to let pairs work for a while, swapping roles as appropriate, and then mixing up the pairs. The navigators at that moment move to a new station and the driver stays with the one they are "driving". The navigator continues to navigate, coming up to speed for a bit. 

However, a caveat, and a suggestion for your overall process. I consider it poor practice to swap roles by the clock. They should switch at natural points. The classic one is that the driver drives until he/she gets stuck and the navigator, who has been really navigating and not just observing, knows how to proceed. Rather than make a suggestion about how to proceed, the navigator just takes the keyboard and continues. This may not be sufficiently often in the classroom as some students will (foolishly) try to dominate and others (equally foolishly) may try to ride along for "free". So...

Another way to encourage frequent switching is to combine pair programming with a strict pre-test rule: No code without a failing test. Switching then goes like this. One partner writes a failing test for the code and the other takes over long enough to (a) make that test pass and (b) write another failing test. Then they switch again and continue. This has been called "heartbeat" switching. It also encourages the navigator at the moment to stay engaged. 

The navigator is NOT an observer. Don't let students think that it is easier than driving. It has an important "strategic view" purpose that complements the "tactical view" of the current driver. With no need to think at the detail level, the navigator keeps the direction of travel in mind. Both participate equally, though differently. Make sure students understand that. The job of the navigator is definitely NOT to get coffee for the driver, nor even to do background research. Both should do those things together. 



For paired/group work that does not involve just programming you should seek to assure that the members of a group don't just "divide up the work" between them, but actually work cooperatively on it for all phases. Students think that division is a great idea until they reach the point of trying to integrate possibly inconsistent separate work. On Agile teams, pairs work together, but the team's pairs work on different things. The daily Stand Up Meeting is the way for all of the pairs to assure that they all work toward the common purpose. So, you might institute a practice of daily face to face meetings in each pair/team so that if they work separately they do so only on small and easily integrated things rather than big chunks that don't necessarily fit together. 



Additionally, in a course that uses pair and group work extensively it is a good idea to use peer evaluation. In addition to the suggestions at the link you can use index cards creatively to capture the individual evaluations and create a matrix form in which to record them. I'm assuming that you change teams/pairs, so that students get to work with a variety of partners. It is really only necessary to record the exceptional evaluations (good and bad). The matrix lets you see not only who is consistently given good or bad evaluations, but also lets you see who gives consistently good or bad peer evals.