How do you deal with Lone Rangers in group projects? We all have them - students who want to write all the code themselves, who don't want to be part of a group project.  They have poor social skills, or they don't know anyone else in the class, or they don't trust others, or they think other people "slow them down".  So they go home after a group project is assigned, write all the code themselves, and bring it back to the first group meeting, completed.

A typical situation is a group project done in a class or lab period over several days. The instructor or a lab assistant is present to watch over the students and give advice as needed. Different strategies might be needed if the project is done outside the view of faculty on the students' own time. 

This could also differentiate depending on whether the situation is the first occurrence (you are surprised by it), or if you are familiar with the Lone Ranger and know he or she has a history of going rogue.

What are your practical ideas for preventing a student from taking over a group project, or dealing with it after it has occurred?



Of note from other posts:

Reading the answers to Techniques for encouraging pair programming and What advantages/disadvantages have you seen with Pair Programming in the classroom offers insight into the problem of encouraging students to actually "work" together, which can be part of the problem here. The real issue, however, isn't that the other students aren't willing to do the work, rather that the Lone Ranger just does all the work, usually before work begins, without the others even having the opportunity to work.

Two other questions, Is it possible to ensure division of labor on a group assignment?, and Problematic student at a very high level, help with creating the environment and assignments to enable group work, and determining if someone has gone rogue and done all the work. Neither deals with preventing the Lone Ranger from repeating once the problem has been identified.
This is really a separate approach from my first answer, which has received some push-back.

It's worth noting that many of these loners are simply students who are substantially ahead of the curve.  One way to really want to engage such students in pair programming is to pair them with each other.  This will create something of a Dream Team.

Give them the assignment, but tell them that their goal is to produce the coolest thing that they can that utilizes the concepts that the lab is developing within the time before the lab is due.  Tell them you're excited to see what they can come up with, that you'll allow them to present their work to the group at large, and that if it's a cool enough idea, you may use it as a launching point for a future lab for later generations of students.

As an aside, there is no reason to restrict this approach to the high-fliers.  It can be reasonable to allow students to propose modifications to the labs if these modifications excite the students.  It involves more work on your end, but you'll get better output and (more importantly) more engagement and buy-in from your students overall.