Reflection

The journey of creating the CalendarApp was a very fulfilling experience for our team of CS + CFM students. From the initial concept, where the group was super keen to do something unique, to the final implementation, we navigated through a bunch of different challenges that significantly contributed towards the successful completion of the project.

During the beginning, the group was brainstorming different ideas for issues we face ourselves to plant the roots for potential project. We ended up landing on this CalendarApp because of the challenges and difficulties that are involved with the course selection/planning/scheduling process. Some of us had to email five different professors just to enroll into CS346 itself due to TST and TUT overrides. As such, there was a lot of motivation from each group member to build this project.

Throughout the project and different sprints, there were many different things that were done to ensure its completion:

• There was a general split between group members, where two focused primarily on the back-end and two focused on the front-end. As such, requirements were completed by pairing a front-end and back-end member together, helping allocate specific tasks and divvying up the work in an effective manner. This made tackling the sprints very efficient.
• We also created a group chat to informally discuss questions and problems we faced as we went along with the process to stay-in-touch and update each other our our progress.
• As the sprints went on, we realized that our initial issues in the project proposal were too broad such that they would need to split up into smaller issues due to the depth of work that was required for the completion of each of them. Following on, we began to split our milestones into smaller more concise issues that allowed us to make appropriate progress as time went on.
• We also made sure that code is always reviewed before merging into main. While we did not enforce this through the branch settings on GitLab, everyone was aware of the best practices of asking for approval before merging. As evidenced through the merge requests on GitLab, all of the major merges were approved beforehand by a member other than the one who submitted the request. The approver also made sure to review most of the code before approving. This ensures that the code merged to main will not break any major functionalities.
• We also tried to do pair programming on hard issues to work on. We mostly adopted the Driver-Navigator style of pair programming. While one person writes the code, the other person helps them with ideas and review the code that is typed in. The roles are then switched later on. We found that this practice really helped us progress through the sprints a lot more efficiently. Often times, when someone encounters a problem, it's very hard to debug with them online through chats. As such, when working together, we can bounce ideas off each other, and debugging becomes a much less tedious task.

In terms of what would be done differently:

• More Iterative Testing: One aspect we would change is to incorporate more iterative testing phases within each sprint. This would have allowed us to catch bugs and usability issues earlier in the development process.
• Advanced Planning for Scalability: In hindsight, a key improvement area could have been advanced planning for scalability. This involves designing the system and database to easily handle increased users and data as the app grows, ensuring a robust foundation for future enhancements and user growth.
• Better Quality Code: Our team was a lot more focused on getting the functionalities done. As such, there were less attention spent on improving the quality of the code. A lot of redundancy could have been avoided by spending more time designing the structure of the code. The use of more suitable design patterns would have helped in structuring the code and implementing reusable code. It would also help in implementing low coupling and high cohesion in our code.
• Better Documentation: I think more time could have been spent in documenting our code and different design decisions. While some of the code is documented, a lot of it was left untouched. As such, better documentation would make our project more maintainable in the long run and also help the team itself in understanding everybody's code.

There were some features that had not been completed or ones that we realized we could have added after the last sprint:

• Initially, we had planned to implement a dark mode setting that would give the user the option to select the visual setting of the application. This was not completed due to time constraints and the prioritization of other core functionalities.
• Since we allow the user to create multiple calendars through the calendar page, the group realized it would have been more effective to create a dropdown menu on the course info page to allow the user to select which calendar they would want to add a course into, instead of just adding the course to the primary "Current Calendar."
• On the wishlist and list of courses on the calendar page, we realized it would be ideal to have made each course on the page clickable such that it would be linked to its info page. This would be ideal in case the users wanted to double-check anything, remind themselves of any course-related information, or see the different sections and their times easily.
• Another feature we wanted to work on was to implement a more robust authentication flow. As of right now, the routes themselves are not really protected, so a malicious person can use our routes without registering or logging in. One idea was to implement tokens to enforce the routes. Once a user registers or logs in, they would receive a token and that would authenticate them for the routes. However, with the deployment on the cloud, the cloud routes also required tokens which made it difficult to implement two layers of tokens. One solution would have been to implement the Google authentication flow through Firebase, but we did not end up having time to look into it.