How many hands make light work in computer science student projects

Almost everyone who has or is currently enrolled in a computer science programme has worked on group assignments.

They’re hated by many, but fact is that such assignments are beneficial for students because they give students the opportunity to work on larger projects and practice their collaboration skills. Moreover, in some situations actively working together towards a mutual learning goal has been found to be more effective than individual approaches. But do students actually get these benefits from group assignments?

Group work can be approached in several ways. Division of labour is a very popular one, as it allows team members to focus on or specialise in specific tasks.

Other methods, like pair collaborations (with two people), group collaborations (with more than two people), and delegation (where one person within the group takes responsibility for a task) are also possible.

These methods can be linked to two common strategies for group work:

• Cooperation, where a group task is divided up and the resulting parts are completed individually by team members;

• Collaboration, where team members continuously construct and maintain a shared concept of a problem.

One thing that makes groupwork in computing education different from groupwork in other fields is that students may enter computer science courses with vastly different levels of programming skills, which strongly affects how and how much they may be able to contribute to projects.

So (how) does this affect how computer science students approach group work?

To answer this question, the researchers interviewed 20 final-year bachelor’s and master’s students from four Dutch research universities about their experiences and perceptions on group programming assignments throughout their studies.

Students described various strategies to divide work among team members, which can be grouped into three themes: project startup, collaboration after initial division, and motivation for work division and collaboration strategy.

Virtually all students mention dividing the group assignment into several sub-components or tasks that team members could work on individually, usually after some sort of alignment process to make sure everyone agrees about the content of the assignment.

Five students mentioned looking at the qualities and experiences of all group members when dividing tasks, while four of the students mentioned that work is divided directly without further discussions.

Once the work has been divided among team members, different strategies may be used to keep in touch. Some teams have regular check-ins, others only get in touch when questions or problems arise. One student mentioned being in a team where no further contact happened between members until the integration phase at the end of the project (side note: This must be one of the worst types of “group” projects?).

Code reviews and pair programming are fairly common in projects. However, not everyone seems to like pair programming because its benefits are seen as questionable, especially when one of the team members has a much lower skill level. Another interesting observation is that students seem to be okay with providing feedback to team members, but not with correcting work done by others.

One student mentions an interesting approach where both group members work separately on the same parts, and then submit the best version of the two.

The most important reason for dividing work among team members is that students believe it helps them get a better grade for their work (rather than learning the most possible).

It also results in less work for each member and can be more effective because it is not always possible for multiple people to work on the same task.

Most students mentioned task allocation strategies in their interviews.

Almost all students mention assigning specific tasks to group members, often based on their skills, experience, interests, or preferences.

For instance, members who have less programming experience can be given simpler, more learning-based tasks, while experienced programmers can take on more/harder tasks.

Other interesting examples include cases where (especially bachelor’s) students gain more expertise in specific areas and thus “specialise” in certain types of tasks. One might wonder whether this is means that students optimise prematurely and if so, whether it is desirable from an educational and career perspective.

Quite a number of interviewees talked about the assignment of roles to team members, specifically the leadership role. A team leader doesn’t necessarily contribute most content-wise, but may be responsible for communication with the teacher, making sure everyone is present, or task division. Groups without a person may become unguided.

Students are well aware of how they approach group work and will try to use division of labour, which is often done by the group as a whole at the start of a project. Some teams may continue with some group activities, like reviews, throughout the project.

Prior programming experience and expertise play an important role in task allocation. The paper mainly discusses the implications for group work done by students, but it doesn’t take much effort to see the parallels with group work done by agile teams in professional settings.

Another valuable insight is that creating assignments for groups of students results in cooperation, but not necessarily collaboration. This does not mean that no collaboration happens: brainstorming sessions, check-ins, and reviews are all signs of collaboration!

Having said that, it is not clear how well group assignments are at achieving the learning goals of computer science programmes.