Peer Collaboration in Practice (and in Theory)
In the recent Secure Software Development module, I had a chance to participate in a group assignment, and I think this experience deserves a dedicated post.
Some context first: so far, each module required three assignments. One of them is usually focused on software design, planning, justification, etc., and is followed by a task to implement the system based on that design.
While the assignment itself was pretty standard and similar to previous ones, this time we had to work in groups on the design document. So, while the idea of working together on something wasn’t entirely new, the group format definitely added a layer of unpredictability—and that’s where things started to get interesting.
So, obviously, group work has a few stages, so I’ll just break this post down into sections.
Forming groups
Luckily, we didn’t have to form groups ourselves — our tutor did it for us, which turned out to be helpful, since most of us hadn’t really interacted before. Sure, there were some forum discussions earlier in the module, but those were pretty formal, so it’s not like we knew each other.
The group lists were shared in the first unit, so we had about five weeks to organize and deliver the assignment.
Organizing teams
One helpful thing our tutor suggested was to prepare and sign “team contracts.” Basically, that’s a document where group members agree on how they’ll split the workload, when they’ll meet, how they’ll deal with conflicts, and so on. It’s kind of the first collaborative task that helps set some ground rules.
If you want to see what that might look like, here’s a list of contract questions from MIT.
It all sounds like a solid start for teamwork—you connect with your team, write the contract, and go from there. But, well, things didn’t go quite that smoothly. Since the course is fully online and doesn’t really encourage student-to-student contact, there wasn’t any obvious way to reach out to each other.
So I waited for about a week, hoping someone would make the first move. Then I remembered that the uni provides Office 365 accounts, including university email, and you can look people up by name. So I did that and sent out a group email inviting everyone to a Discord server I set up.
That was the first actual step forward. A few students replied and joined the server, so we could finally start drafting the contract and talking about the assignment. But not everyone did that. And I get it — they don’t owe me a reply. Still, it was hard not knowing whether they didn’t see the email and were still waiting for someone to reach out, or just didn’t plan to participate. And without knowing that, it wasn’t clear if we should move forward with just the active members, or wait and see.
Eventually, with a bit of help from the tutor (and some stress-driven decision-making), we submitted the contract — with, I think, one person missing — and moved on to the core assignment.
Working on the assignment
Once the contract was out of the way, we could finally settle on the domain of the app and start figuring out how we wanted to implement it.
These sessions turned out to be pretty insightful: just like siloed teams in large organizations develop their own approaches for similar issues, I would say the same happens in online education as well. Even though we are all presented with the same (or very similar) assignments, we all have different backgrounds that influence the decisions we make and approaches we take when designing software. And this assignment really offered the chance, if limited, to share some expertise and get a fresh perspective on some things. For example, the earlier assignments also involved server–client elements, but for some reason I never considered actually using local network connectivity to implement it. If not another student on the course, I somehow probably wouldn’t even think of it; the idea completely slipped my mind.
That said, syncing schedules was tough. The students who engaged in the activity (and I among them) didn’t always understand whether we need any input from others, some of whom dropped off the radar entirely. Still, the few calls we managed to organize were super productive. No surprise there: sometimes real-time chats just work better than endless messages.
Preparing submission
Even though we said we’d try to use Agile in our contract, we lost so much time just trying to get coordinated that we gave up on that idea and split the work by domain instead. Honestly, that worked pretty well.
The tricky part came later: putting it all back together. Even though we all worked from the same basic idea, everyone had slightly different interpretations, so we had to do some changes to make the parts line up.
Unfortunately, some of the earlier issues came back: a few people who had taken on parts of the work just disappeared, without any notice. Again, I get that we’re not reporting to each other, but still — we’re joined at the hip here, so a quick heads-up would’ve helped.
Grading
As I mentioned, we ended up submitting an incomplete assignment. Sure, we could’ve picked up the missing parts ourselves, but at that point we were running out of time.
Luckily, group grades don’t only depend on the design document. There’s also a peer review form that we all have to fill out. It asks us to reflect on how much each person contributed, and the tutor uses it to adjust the final grades—so hopefully, not everyone gets the same mark regardless of how much they did (or didn’t) do.
Wrapping up
Overall, this was a pretty mixed experience. I’m still not sure if I’d want more group assignments like this in the future. Group work in uni is just not the same as in real jobs, at least in my experience. People aren’t always motivated or available, and it’s tough to get everyone aligned, especially in online courses where everyone has their own schedule and level of commitment.
That said, I really enjoyed connecting with other students, sharing our experiences, and getting different perspectives. That made the assignment genuinely memorable, even if it was also a bit of a headache.