Group Project Survival Guide for Singapore CS Modules

If you're studying computing at any Singapore university or polytechnic, you'll get group projects. Lots of them. CS2103T at NUS, IS200 at SMU, INF1002 at SIT, every project module at every poly. Half of them go fine, half of them collapse, and the ones that collapse all collapse the same way.

Below is what works, drawn from the patterns I see most often.

The four group archetypes

Every group of 4 in a Singapore CS module has roughly:

1. The driver: usually one person, often you if you're reading this. Cares about the grade, willing to do the work, sometimes too willing.
2. The competent passive: knows how to code, will do tasks if assigned, won't volunteer.
3. The well-meaning slow learner: trying hard, but can't move fast. Needs help, often doesn't ask.
4. The vanisher: replies on Telegram once a week, shows up to demos.

The mistake the driver makes is to do the vanisher's work themselves to keep the project moving. This is short-term rational and long-term toxic. By week 8 you're doing 60% of the work. By week 12 you're doing 80% and resentful.

Don't do this. Here's the alternative.

Establish working practices in week one

The first meeting isn't a coding meeting, it is a norms meeting. Decide:

1. How you communicate. One channel only. Telegram or Discord, not both. No email.
2. When you meet. Same time every week, 30 minutes. Skip if nothing to discuss, but never skip the meeting "because we are busy".
3. How you assign work. Use a shared board (GitHub Issues, Notion, Trello). Every task has an owner and a deadline.
4. How you review. Pull requests, with at least one teammate review before merge.
5. What "done" means. Code merged, tested, deployed to staging.

Write these down. Put them in the repo README. Refer to them when someone slips. Norms agreed in week one have authority that norms invented in week eight don't.

The Git flow that works

For a 4-person team on a 12-week project:

• Main branch: protected, only PRs can merge. Always deployable.
• One feature branch per task. Named feat/login-page, not chris-stuff.
• PRs require one approval. Not two. Two slows you down. One catches the obvious mistakes.
• Commits are small and named clearly. "Add password validation" not "WIP" or "fixed bug".
• Merge once a week minimum. Long-lived branches turn into merge-conflict nightmares.

If your team has never used Git in a team setting, spend the first hour of week one on a hands-on workflow walkthrough. The cost of a teammate force-pushing over your work is much higher than the cost of an hour of learning.

How to deal with the vanisher

Every group has one. The escalation ladder:

1. Week 2-3: Send a friendly DM. "Hey, you've task X due Friday, just checking in." Sometimes that's enough.
2. Week 4-5: Bring it up in the group meeting. "Vanisher, you've not pushed code in two weeks. What is going on?" Make it a group conversation, not a personal one.
3. Week 6-7: Document. Email the module coordinator. Most modules have a peer-rating component. Use it honestly.
4. Week 8+: Stop covering. If the vanisher's part is missing, let it be visible to the marker. Don't absorb their work to make the team look good. The marker won't reward your sacrifice.

Step 4 sounds harsh. It's the only thing that actually changes behaviour. Vanishers vanish because covering exists. Stop covering and they either show up or they don't, and the marker sees the truth either way.

How to deal with the well-meaning slow learner

This is the opposite problem. They want to contribute, they just can't move fast. Approach:

• Pair them with you on the harder tasks. They learn, you cover.
• Give them the well-defined tasks first. "Implement this exact function" is easier than "design the auth flow".
• Schedule a 30-minute teach session weekly. Investment that pays back in week 10.

Don't try to carry them. They lose the chance to learn, you lose your sanity. Carry them only on the day before submission, and even then only on the parts that affect the grade.

CS2103T-specific advice

NUS CS2103T deserves its own section because the iP and tP have specific marking patterns:

• iP weekly increments: do them every week, no excuses. The compounding effect is extreme. Skipping week 4 means week 5 takes twice as long.
• tP feature ownership: every team member should "own" 1-2 features end-to-end. Not just code, also tests, docs, and the user guide.
• PE-D and PE-R: the peer evaluations matter and they ask for examples. Keep a personal log of what you and each teammate did each week.
• Documentation: the marker reads the dev guide and user guide carefully. Spending a weekend on docs late in the project is worth more than another small feature.

Marking patterns to know

Most Singapore CS group projects mark on:

• Working features, weighted by complexity
• Code quality (readability, modularity, testing)
• Process (Git history, PRs, documentation)
• Team contribution (often via peer rating)

Notice that "amount of code" isn't weighted. A small, clean, well-tested feature scores higher than a sprawling buggy one. This is good news for the well-meaning slow learner and bad news for the driver who tries to do everything fast.

Submission week strategy

In the last week:

1. Stop adding features by Tuesday. Last-minute features are buggy.
2. Spend Wednesday on testing and bug fixes.
3. Spend Thursday on documentation.
4. Friday is for final demo prep and a clean Git history.

Teams that try to push features into the last 24 hours regularly break the demo. Don't.

Conflict happens. Handle it directly.

If a teammate is being unreasonable, say so. Privately first, in the group meeting if private fails, to the module coordinator if all else fails. Don't stew.

Most conflicts in CS group projects are about expectations, not about people. If everyone agreed at week 1 what done meant, there is little to fight about. If you skipped that conversation, week 6 conflicts are predictable.

If your group is already on fire

If your group is collapsing and you have to salvage the project, message me on Telegram. I've helped students rescue tP and IS200 final projects in the last week before submission. Doable, but the earlier you ask, the smoother it goes.

And if you're the driver and burnt out, take a break. The grade will be roughly the same whether you spent 50 or 100 hours, within reason. Pace beats sprint.