ICS414 Reflection - Git Happens
16 May 2025A Hopeful Start
At the start of this semester, I approached ICS 414 with a lot of hope and optimism. The way the course is structured - centering around a semester-long project - was a nice change to the usual weekly assignments and examinations. I appreciated the flexibility of not having to attend regular in-person classes and instead being able to focus on collaborative work with my group. This format gave me a more realistic idea about software development in the real world, where communication, collaboration, and consistency are just as important as the code itself.
Split Team, Split Sanity
As good as it seemed, the experience wasn’t without its shortcomings. Working in a group where we didn’t frequently meet in person came with its own challenges. One major problem was the choice to split the team into a front end and back end format. While such a division makes sense on paper, especially when it comes to larger and more complex projects, it ended up doing more harm than good in ours.
Such a separation led to frequent misunderstandings and inconsistencies in how our code was supposed to interact. Without regular and clear communication, the boundaries between the two groups got slightly hazy, and expectations often fell short. This imbalance also resulted in some group members - myself included - taking on more complex issues more often during key stages of development.
One Man, One Branch, Many Commits
On a personal level, I struggled with maintaining a steady pace of contributions. My schedule often forced me to work on the project in bursts, where I dedicated long sprints of time to coding and pushing all of my changes in a single commit, even when it dealt with more issues outside the scope of the issue name. This made it appear as though my contributions were less frequent, even though I took on some of the most complex and time-intensive tasks for the front end of the application.
In hindsight, a different project structure, as mentioned above, where every member was responsible for developing a self-contained part of the application, would have been more effective. That approach could have minimized the dependency between team members and allowed us to work more independently without being bottlenecked by another’s progress.
Lessons Learned
Despite all this, the project taught me a lot of valuable lessons about teamwork, communication, and adapting to challenges in what I believe was a real-world coding environment. While our end product was great, it was nowhere near perfect, yet still the experience gave me valuable insight into how group dynamics and project planning can make or break a software development effort.
It reminds me that technical skill is really only one part of it - and that being able to collaborate, compromise, and adapt is as if not more vital for success.