Group projects suck

There is not a single story I've heard from friends or other developers where things end up exactly as planned. I'm not even suggesting that perfection is the ideal outcome, but the ways that teams fall apart are usually predictable, pathetic, and/or painfully obvious in retrospect, especially to an outside observer. Now, extend this to undergrad group projects full of inexperienced computer science students, and now I'm wondering how half these people even made it past year two.

Best case scenario, the team is excellent, everyone gets along, and productivity is consistent. Maybe life decides that life is too comfortable and fucks you over, like bricking your computer with unsaved important work... Worst case, the team is basically a team by name only. Some members go catatonic for days, only to vomit up the bare minimum amount of sloppy code. The others have manifested some passive-aggressive pact and can't finish a sentence without hiding their spite for everyone. Oh, and like two other guys still recovering from their tragic coma since the first meeting, three months ago. Honestly, it'd be preferable that the disappearing programmers were actually in a coma, at least then there's an actual reason why their last git commit was two weeks after starting development.

Anyways, I'm not here to debate about collaboration in society, or about social media, or vibe coding (despite my instinctual desire to slap the Instagram Reel brainrot out of the energy drink addict, sleep-deprived teammate). This is just my retelling of prior group projects, and passing the lessons I've learnt to you -- the unfortunate reader who's made it this far and will sunk cost fallacy all the way to the end. I guess this also counts as my therapy for the stress of surviving a bad C.S group project, yet my bipolar ego tells me that I came out of the experience better than the others, so obviously my opinion is more important — trust me bro.

Software Development 301 (how do i agile again?)

This was my university's introduction class to proper object-oriented programming (OOP), software development pipelines, and Agile practices. Actually relevant for anyone working in a software company, so naturally everyone recommends CMPUT 301 as a must-take class for computer science. Now, if only the class were organized well, or hired a competent tenure professor who doesn't fumble the class size down to under a dozen ~~survivors~~ students. Regardless of the content (it was fine), the lab portion is what won the reputation of the C.S. degrees final skill check.

The final app, Pekkas, can be found here

I want to dropkick Android Studio

Between the smaller labs, the big project was developing an Android app where users and organizers can host and join events, stored on a Google Firebase database. The first few weeks were suppose to teach us the basics, but with how bloated and cumbersome Java for Android was, any deviation (ie making a real app), from the simple examples, required a hour detour of either Gradle reconfiguration, even more boilerplate code, and/or yet another copy paste from the docs/AI while barely understanding how or why that works. If Gemini wasn't integrated in Android Studio, I would have bashed it even harder for being so comically slow on Windows/Mac — Notepad++ would be preferable.

Combined with 3-4 other classes worth of coursework and labs, everyone was already stressed and busy busy. Even still, some great teams of six ended up with some clean-looking apps. When working with the right people under the right system. For my team...

It was not a great team of six

...and I can't even blame anyone individually, we were inexperienced developers after all. In this case, no one was necessarily a bad "coder"; everyone was an above-average student, but strong technical skills don't translate to cooperative/soft skills needed for communication and teamwork. There is a fundamental mentality shift between solo and team development, and none of us was prepared for what came next.

Originally, my group of friends planned to form our own team, but they also promised to team up with some other friends, who then promised to team up with their other friends. One thing leads to another, and I end up stuck with mostly strangers and people I've seen briefly but never talked to. Perfectly normal to work with strangers, it's a big world, but everyone else there was already friends with each other, and I ended up being the outsider among their group. So when everyone started talking in private Dm's, guess who got left behind?

Communication is hard

If there was one takeaway from this group project, it's how damn important communication is to maintain, and how easy it is to neglect. It hurts even more that I was one of the bigger contributors to this issue. The biggest enemy was assumptions, like assuming everyone is telepathic so they always know what your code is doing, or assuming that everyone read your 9pm message explaining the code and no one could possibly have questions. These assumptions lead to laziness, which for us meant that:

• Meetings were never held weekly - "Too much effort and hassle"
  • Without scheduled meetings, assigning responsibilities and tasks was difficult; nevertheless, getting everyone together online
• We weren't communicating effectively about what work was in progress or finished
  • We never determined a central system to store and maintain updates, progress, and tasks. While we did have project management tools like GitHub and Discord, people were fragmented on what they used, meaning our progress became fragmented.
    • Most info/communication was shared only by texts or DMs, and would often be lost, never seen, or forgotten.
  • Once again, with the assumptions, we'd just send a message stating that something was done, sometimes update the project board, and move on. Due to our lack of bookkeeping, these messages weren't recorded somewhere that could be reviewed, and we'd have to scroll through chat logs to find them.
  • As an example, after making functions to handle database logic, I would post a message in Discord about what I've done and nothing more. Obviously, when that message gets lost in history, that info disappears, people miss the message, and we end up with redundant work and more confusion.
• Project boards weren't updated
  • Normally, a project board keeps track of tasks and their status. However, members like me forgot to mark off tasks once they were completed. Compounded with the lack of oversight, or people even checking the board for tasks, work was distributed by first dibs.
• We were merging code into main without enforcing code reviews
  • Okay, this should have been obvious, but broken code was missed and merged into main more times than it should have.
  • Testing (Unit, UI, Builds) was also neglected. While tedious, it is still important work that would have caught most of these issues.
• Documentation was only updated days before a deadline
  • It was seen as unnecessary busywork that was only required because our TA marks our code for "quality".
  • Undocumented code meant starting at unintelligible code and figuring out what it does yourself.
• The Discord group chat was just that, a single chat with no channels to organize conversations
  • ...and was probably why people were DMing each other outside the group chat.

The result of all this is a project where tasks were done with no coordination, missed by other people, and so we were always confused on who or what was even being worked on. Constant issues with duplicate work, confusion about why and how to use said work, and someone getting away with doing (almost) nothing just because we never properly sat down and assigned tasks to the team. Needless to say, we sacrificed many, many hours, to compensate for our mess.

Reflecting (don't worry, scary android cant hurt you anymore)

At the end of the term, I received a 4/7 by my teammates, primarily due to a lack of communication. It's ironic they never communicated to me that they wished I was communicating more — I did deserve the low mark. Even after submitting the final app, my feedback also noted that the others couldn't remember or write down my contributions to the team. In retrospect, my long and detailed discord messages with nothing else to supplement them were pretty unremarkable. Heck, I had to dig through months of Discord messages just to remember everyone else's contributions.

Honestly though, my body sorta just forgot about the stress right after the final due date, and the months of anguish don't feel as bad as I recall. Similar to the myth of women "forgetting" the pain of childbirth after delivering a baby. Of course, it would be a stretch to compare a bad group project to childbirth; you get to stop babysitting after the group project is finished.

Thinking back to my original group of friends, their split-off team had similar issues of miscommunication and two members who did basically nothing. While apparently they were really slow in finishing their tasks, it's also the team's responsibility to hold everyone accountable and assist in getting the work done on time. No one wants to fail the class (hopefully), so might as well try to force everyone to stay involved. I get that, especially in junior year classes, there exist slackers, who refuse to contribute anything to group projects, their heads so perfectly shaped to slam into their IPhone 14 Pro playing hustle-maxers podcast clips at 200% speed on TikTok, but it's just not worth the punishment after the TikToker passes out from the head trauma, and suddenly your the "bad guy" trying to help the team "escape" the slacker via your "aggregated assault".

Game Development 250 (for the gamers, but the gamers are....)

Logically, my next semester just needed another massive computer science group project, because my five-class schedule was shy of being too manageable. It also says a lot when it took until my third year of university to take a C.S. class where I was actively interested in the content, rather than just my degree requirement. This class is split between lectures, covering game design topics, and labs to build games in Unity. As a gamer, I grew up playing video games during the Wii into Xbox One era, and had experimented with making games during high school. Plus, with my experience of one group project, I came into this class with prior knowledge and confidence. So, of course my next group ends up with a new set of problems, at which point I have circled to experiencing every possible thing to go wrong.

The final game, Doubt's Horizon, can be found here

Unity? More like (L)nity because L = loser and uni...

Beyond the gradual decline of Unity since their new CEO in 2019, and the myriad of controversies up to his resignation, I'm more mad that Unity for Linux STILL CAN'T SCALE THE UI. Tiny ass 8px font on my high-res monitor means I need to squint when reading, and constantly miss clicking when doing literally anything. Also, older (and arguably better) Unity versions require deprecated packages, and crash whenever I try changing my layout. Unity scenes are also just one giant file, with the consequence of endless Git conflicts when two people dare have the audacity to work on the same scene in the game engine software.

The indie game developer to crashout pipeline is REAL

The ultimate assessment of CMPUT 250 is making a short, fully developed indie game within a semester. To help set the mood, anyone familiar with the industry can also search "indie game dev burnout" to evoke their weekly doomscrolling session about the dying industry. I pushed on anyways, optimism in my heart that maybe, just maybe, my group will be different, that things will go to plan for once.

After our initial pizza social, I end up with a pretty strong team of six. Five of come from a C.S. background, with only me, seconding as an audio engineer, and our artist, being focused on creativity. The first two weeks go by quick as we ideate about our game. This time, we're actually meeting fairly frequently, listening to everyone's ideas, and organizing them on Google Docs so people actually know what's going on.

We also designated two lead roles who kept the team organized. Our creative director and artist had experience working and playtesting on prior games. He developed the initial systems for animations, UI, and specific Unity tricks while the rest of us had to catch up on. Our producer was an experienced intern at a large company. He oversaw our GitHub and pull requests, arranging two meetings a week where tasks were assigned in proper sprints, and always tried to answer our messages in a proper Discord server (with channels). They were all great bosses who didn't order people around, but actually worked alongside their employees/us.

Then one guy drops the class, and we're down a member. Great. He realized how much work he couldn't commit and collapsed under the pressure -- oh well. If only he dropped out on not the dropout deadline, so no other students could enroll in his place.

Didn't matter, or rather we couldn't let it matter. Scripts, project boards, and tech demos were still due with no consideration of our crippling lack of manpower. So we push on, with the first month going by pretty well. Then our creative director gets hospitalized... He's probably fine, we occasionally got the "I'm alive and working" text, but school is over and I still haven't seen him since. It was a stressful four months.

Planning is even harder

Even before the whole double vanishing act, unscrewing the wheels off a dying kid's wheelchair, whatever metaphor you prefer, etc, our biggest problem was not accounting for the fact that our only artist isn't arting, and the vertical slice was due in a week. Comically cruel events like these can't be predicted, but when they do, you just gotta get on your knees and take it like a champ. Swallow down the sorrow, wipe yourself off, and prepare to judge-jury-executioner those cool ideas which will never see the light of day again. For your consideration:

• Our artist wrote the initial code. Okay let me explain...
  • He was the most experienced with Unity, so we just trusted that his prototype was perfect for what we wanted.
  • He was also unexperienced coding in a team. Tightly coupled/inflexible designs, nothing was documented, and didn't know how to use Git.
    • Our worst incident was when he made multiple massive, game-breaking rewrites on core systems. Even worst, no one realized that he never pulled new changes from main for three weeks, meaning three weeks worth of work just became incompatible. That branch should of be thrown away, but our producer committed weeks to resolving the 20+ file merge conflict.
  • Also when the artist disappeared, it took us a while to figure out how his systems worked, especially Unity specific jank.
• After losing two out of six members, it took too long to adapt our workflow
  • We were huffing straight copium, ultra-denial, that our artist's medical condition wasn't that bad, that they would come back a-okay, wonderful art in hand, and said art would not be destroyed when his laptop kills itself with no backups — Best Buy never managed to repair it...
    • The universe was in a sadistically cruel mood that day.
  • We pushed forward by stubbornly focusing on features and bug fixing, assuming that the art will be done eventually.
• The remaining four of us were programmers and were stuck in the technical programmer mindset
  • Honestly, this is where my other teammates may disagree, but 90% of our focus was on code stuff and new features. Artistic elements like writing, audio, and level design came as an afterthought. As the audio engineer who composed the soundtrack, I wish I had more time to make music and less time on coding.
  • It's really easy to tunnel vision on a specific thing and miss crucial issues within the whole project. Our weekly meetings let us discuss everything that's been done and needs to be done. Most importantly, triage whatever we had left and cut content as needed.
    • For example, we only started making our tilemap two weeks before beta.
• Deadlines deadlines deadlines
  • In proper game studios, losing a third of your team would mean delays. Unfortunately, this class has no extensions, so we just had to push through deadlines after deadline, even as we slowly fell behind the rest.

The end result of all this was crunch. Like the most amount of crunching any of us ever went through, like daily all-nighters where I wake up every morning to 80+ commits from the nocturnal 3am-ers. All my other classes were neglected, replaced with the ultimate goal of just finishing the damn game. The day we submitted the final game was the most satisfying sigh of relief I ever experienced.

Suffering builds characters - says my senior, not currently suffering

The little reprise my team received was a solid grade for the game (with pity points for the art), and an A for the class. Our efforts were acknowledged, even though things strayed so far from the original plan. Then again, it's more common that plans fall apart and are rewritten.

I will say that this experience taught me more about game development than an entire year of Unity/Unreal/Blender/Photoshop tutorials. It's terrifying how much faster I learnt while under deadline constraints and expectations of my peers. Sure, this may be obvious to some people, but think about when and how often do opportunities like this appear? The strong-willed can set their own schedule, but for many others, this high-stress fire burns only from school or work -- avoiding the stress in their off time. It's not right to just tell people to lock in and chase their passions; maybe they could use an opportunity to discover that capability for learning.

Unlike my previous software group project however, good organization, frequent communication, and a unified goal of getting the damn game finished actually brought us all closer together. I didn't hate my first group, but our game dev team all became closer as friends. Our trauma bonding turned into real bonding. The difference being that you actually want to hang out with the others after the project is done. Even if we don't see each other ever again, at least my brain picked out the good memories so the eventual midlife crisis reminiscing about the glory days will feel better than they were.

Conclusion

I'm sure everyone has dealt with peers before, and even more have their own ideas about group projects. This blog wasn't aimed at answering such a general question, but merely to share what went wrong with my previous group projects, and what I learnt from them. If I were to summarize everything into three points to remember:

• Learn to communicate - listening to others, sharing your thoughts, debating ideas
• Don't cling onto your ideas - be okay with doing things differently
• Be patient with others - everyone is in this together, work with and around the situation

How one goes about mastering these skills is not definitive or absolute between individuals, but something to figure out by experimenting. Frankly, it's fun listening to other classmates shitty group projects firsthand, the different shades of horror from crazy insane and/or sheer incompetence. What I can promise is that there is no faster way to learn than a Trial By Fire, either to emerge stronger or die trying!