9
$\begingroup$

Let's say I've assigned my Intro to CS class their first group programming assignment. A common problem is that the most invested student in the group will end up doing the majority of the work. At grading time, there are techniques that can be used to determine how much work each individual did--I don't want to focus on that. Instead, I would like to hear if there are any ways to ensure that the group actually divides up tasks proportionately without planning their project for them.

Is this possible? If so, how? More importantly, is it possible to do this without external pressure? How can we give them the incentive and tools to really want to cooperate?

Assume that the class has been introduced to OOP and has completed a few assignments, but exposure to CS is minimal.

Bonus: Is it actually better for the students' education to ensure this or to leave them to their own devices?

$\endgroup$
  • $\begingroup$ Even in industry there is no way to break up tasks proportionately. Databases are trivial to me, but web interfaces are hard. My partner is a rockstar with node js, but really had no clue about how an RDBMS works. Our division of labor is obvious, but is there any way to say they are equal? $\endgroup$ – pojo-guy Jan 1 '18 at 15:03
10
$\begingroup$

Make each group member explicitly be 'responsible' for one aspect of the project.

Let's think about why group work is a useful tool in terms of teaching your students. I'd imagine one of the big reasons you would assign a group task is to prepare your students for a job, working with a team to build a product. In the workplace, you typically have a way of assigning individual roles and responsibilities; if you're building a website, you generally would have someone responsible for design, someone for the backend logic, etc.

You should do the same thing here. Specifically require that your students build a plan, with each member being given a role that they are individually responsible for, and before allowing them to proceed, make sure each role is relatively equal in scope. You wouldn't want Alice to have ten times the work of Bob in the plan—it won't give you the scope to analyse each bit of work individually.

Obviously, each piece of the project likely depends on another, so it's very difficult to isolate each person's contribution individually. That's why I'd suggest not weighting the group work too highly, because the difficulties of evaluating the outcome far outweigh the benefits of making the group work count for a high percentage of the grade.

Carnegie Mellon's Design & Teach a Course section has some useful tips:

In addition to evaluating the work of the group as a whole, ask individual group members to demonstrate their learning via quizzes, independent write-ups, weekly journal entries, etc. Not only does this help you monitor student learning, it helps to prevent the “free-rider” phenomenon. Students are considerably less likely to leave all the work to more responsible classmates if they know their individual performance will affect their grade.

To create individual accountability, some instructors combine a group project with an individual quiz on relevant material. Others base part of the total project grade on a group product (e.g., report, presentation, design, paper) and part on an individual submission.

You'll need to think about your aims. Do you want to test the group's ability to spot people not contributing as part of the teaching? If so, don't put in those safeguards, and see what happens. If you just want to test their CS knowledge, make sure that you can fairly evaluate individual contributions, as well as the overall result.

$\endgroup$
  • 2
    $\begingroup$ I do like the idea of injecting a little bit of project management into the assignment. That's also an interesting note about there possibly being value in testing their ability to spot people not contributing. $\endgroup$ – called2voyage May 23 '17 at 14:36
  • 2
    $\begingroup$ In practice, I've found "make sure each role is relatively equal in scope" is prohibitively difficult, and many times easier said than done. I'm a fan of running N x small projects, and telling each student they will have to do EVERY role once, encouraging them to help with the process of balancing the roles, knowing there's nowhere for them to hide. $\endgroup$ – user31 May 23 '17 at 14:44
  • 2
    $\begingroup$ @Adam That sounds like the start of an interesting answer. $\endgroup$ – called2voyage May 23 '17 at 14:53
2
$\begingroup$

Break the project up into separate, independent components that must work together and assign each one to a different person or group. This simulates how software is written in the industry.

This could be one person doing a different layer of the stack (front end, middle tier, database), or it could be different stacks/services that must operate together (one to authenticate, one to place an order, one to fulfill an order, one to send a receipt, etc).

Using contract driven development, the project could start with a spec being defined for how the different parts of the system will operate with one another and then each developer or team would be responsible for their part and no other parts.

If you use version control such as git it is also a simple matter to see who checked in what code, and how often.

In my experience in over 25 years in the software industry, 80% of the work is usually done by 20% of the people, sometimes even more extreme (90/10 or 95/5). The best developers are not 10% or 20% more productive than the worst, but 10x or 20x. Too many people get good at asking other people to do their work for them rather than doing it themselves. I think it would be great to teach every student to pull their own weight.

$\endgroup$
  • $\begingroup$ Interesting answer. Breaking the project into separate, independent components is what I ended up doing as a student when I was a member of a group assignment. I still ended up doing a majority of the work. However, using version control, as you and others have pointed out, would have shown who performed what, at least in my case. $\endgroup$ – called2voyage Jun 28 '17 at 15:02
  • $\begingroup$ Even commit logs would not prevent the software equivalent of plagiarism but in the real world it often happens that different individuals or teams are given separate assignments and the system is architected in such a way that they can all work independently without blocking each other until integration time. $\endgroup$ – Uncle Long Hair Jun 28 '17 at 15:14
  • $\begingroup$ In my case it wasn't plagiarism because the others weren't passing my work off as their own, but you could certainly structure an assignment that way (where others helping complete a component that is not theirs is plagiarism). I'm not sure how useful that structure would be, and as you say you can't really get around that with just version control anyway. In any case, version control is not a fix-all for sure, but it would have solved my team's problem when I was a student. $\endgroup$ – called2voyage Jun 28 '17 at 15:17
1
$\begingroup$

Aurora's answer is excellent, but I do feel I have one thing to add that's very specific to CS: this is a wonderful opportunity to use (or abuse, depending on your perspective) version control.

There are a lot of great reasons to introduce your students to version control, most of which I will not mention because they not directly relevant to the OP's question. The one reason that is relevant: I've had students use GitHub, and as a result have been able to see exactly who was committing which bits of code and at what times. That solves your immediate problem of ensuring that everyone is contributing to the project, or at the very least, allowing you to identify those who didn't contribute their fair share/only made "easy" updates like code formatting or comment changes.

This also helped me to see who was having problems with the assignments in... not exactly real time, but definitely as the assignments were progressing, rather than after the due date (when it would have been too late to help) or 100% dependent on the students asking for help. I as a TA/recitation leader could then help people when things were more manageable and prevent problems from compounding or a chorus of last-day requests for emergency help and extensions from arising.

Now, I realize that this sounds more like "determine how much work each individual did" than "divides up tasks proportionately." However, experience has shown me that if you tell people about this system upfront, the students will in fact end up dividing the tasks up proportionately. Just having them know that they're being watched seems to be enough motivation to achieve your goal, in practice.

$\endgroup$
  • $\begingroup$ I like this method: being able to see their individual commits would help. $\endgroup$ – called2voyage Jun 28 '17 at 13:25
  • $\begingroup$ @called2voyage all seeing the commit log tells you is who was at the keyboard when the code was committed. You can't see the teamwork process or relative effort from commit logs. $\endgroup$ – pojo-guy Jan 1 '18 at 15:07
1
$\begingroup$

I have a very different perspective that the other suggestions made here. Others seem to say that a group assignment shouldn't really be about cooperation and working together, but about dividing it up - externally. I think that the concern is about easing the grading process, but I would rather be a teacher than a grader.

In the real world that students will later face, both in education and in the workplace, they will be asked to actually cooperate in the work, not just divide it up. When divided up and someone fails to fulfill his or her part, the project as a whole may fail even though most "did their part". This is unacceptable and will leave most of the "group's" members frustrated.

It is also easy to demand that everyone is individually responsible for everything, which sounds good, but is unrealistic. Often in such divide work situation, the other students don't realize, or have any reason to suspect, that they have additional, major, last minute tasks to do.

The first thing you need to remember is that students need to be taught the things you want them to learn when they don't already do it naturally. You need to use some class/lab time to actually demonstrate group work and work sharing. You also need to monitor it either directly or via some sort of feedback mechanism with counseling.

The next thing you need to realize is that in a group, not everyone needs to participate in the same way - coding, for example. Organization is important. Research may be important. Easing interpersonal conflicts may be extremely important.

Next it is necessary to know that not everyone participates the same amount in each small time period, but may do so over time. One of the big ideas in group work is pay it forward. Make a lot of contributions early on so that if you cannot do so later you have still done your share and others won't disparage your contributions.

And of course, not everyone participates equally over time, either, and it is difficult to make it so. Instead you can use some form of "safe" peer evaluation of the members of the group so that you get insight into who the main contributors are. But don't be naive in this either. If all of the questions on your peer evaluation form are about, say, coding, then you are devaluing other sorts of contributions. I prefer to ask students to name one (or a few) key contributors to the group and to say why they were chosen. I also ask each student to specify their own personal contribution. Someone who does all the work him/herself isn't a contributor.

Group work should be done by a group. Don't neglect the social aspect of it. Work within your class framework to bring people together so that they actually have positive feelings for one another.

In a classroom situation learning is the main goal, not the completed project. The project itself can fail if the learning is good. This is different from the real world, of course, but the classroom should be a safer place to make mistakes, provided that the important lessons are still learned.

Note also, especially for a programming course, that even if some student didn't do much of the coding, it is still possible to assure that each student understand the whole work, not just their part. This again, isn't "real world," but is necessary to the educational process. This assurance can be gained in interviews, presentations, or quizzes, for example. This is a variation on the "everyone is responsible" rule, in fact. Everyone is responsible for knowing.


Finally, let me note something from the real world. Many Agile Software Development groups have a rule that no code can be committed to the code base if it was written by an individual, rather than a pair. Some programming is done by individuals, but only for experimental purposes to test out an idea. If the idea proves fruitful, the experimenter works with a partner to create the committable code.

The reason for this important policy is that any team doing real work wants a large enough Bus Factor so that if one or a few key people leave they don't take all of the knowledge of the project with them. This actually applies also to student team projects as some students do, in fact, leave a course in the middle of a project. The others must be able to carry on.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.