SE 371: Project 2
Published: 2023-10-25 19:37:20

**Project 2: Part a** 

Our first meeting went quite smoothly since we just went over the guidelines of the project and chose our roles. I got chosen as the team lead, and we were assigned other roles such as the team liaison who oversees communicating with the team we designed for as well as the team for which we will be implementing our design. We looked over the rules for the SpinList and decided to come up with some ideas on our own and reconvene in a couple of days. 

In the second meeting, we shared our ideas and started working on the diagram as well as the design document for the other team. This part of the project had a slow start mainly because my group and I were lost among the instructions for designing the SpinList class. The guidelines are intentionally vague to give us more control over the project, but instead, it left my group confused as to what to do next. We were unsure if using a Linked List was required or if we were allowed to use any other data structure.  We decided it would be best to end the meeting and hold another meeting the next day after we received clarification from the professor. So as team leader, I typed out all the questions we had and typed them out then @ the professor in our team's group chat. That way every member would have access to the response. 

For the third meeting, our group worked on the design document and diagram together. We were able to get some of it done during the meeting together, but not as much as I would have liked since the design document was due the next day. Since the meeting had already reached about 2 hours and a half, I thought it would be best to just end the meeting and have everyone sign up to work on a part of the document separately. If any of us had any questions, we could just ask them in the group chat. This structure of working on some stuff together and then dividing the work amongst us has been quite successful for our team. Our group cut it close to the deadline but ultimately, we got our design document turned in on time. Our design was for team 7 and they didn’t seem to have any issues with our design or document, they only had small questions here and there so I’m happy about how our design turned out. 

**Project 2: Part b**

The first portion of part b went smoothly. Our team liaison received the document from team 5’s liaison and posted it into our chat the moment they received it. We held a short meeting two days after the SearchList document was given to us by team 5. This gave our group time to look over the document before our meeting. We kept this meeting short since it mostly consisted of us deciding how to divide up the work among the entire team. At the end we had each member sign up to work on two methods, some methods having two members working on the same one just in case one member couldn’t figure come up with a working solution. We decided to set up a meeting two days later because we knew there would be a lot of work to be done for this part of the project. We used the next meeting as just a check-in. As the team leader, I tried to continuously decide a date by which we should have something done to ensure we were on track to finish by the deadline. 

The second portion of part b was the most difficult part of this entire project. After we had some methods completed, we slowly started pushing and merging them into the main branch. It took us an hour to figure out an approach to combine our methods into the SearchList class without any issues. At first, there was no issue since we slowly combined the first few methods. Problems started occurring after we merged multiple pull requests in a row. We found out that somehow our code became corrupted within the process and there were errors everywhere. Two team members who are more experienced with GitHub were able to figure out what happened and resolve the errors. Moving forward, we still had unit tests to put into main but due to time constraints, my team decided it would be best if we combined our code a separate way rather than creating pull requests. We didn’t want to risk corrupting our code again so close to the deadline. Instead of combining our unit tests through GitHub, we just sent our tests in a file to one member who was in charge of writing the main method (one of the requirements from the SpinList document).

My group and I spent many hours together in a meeting trying to figure out how to implement the SpinList for team 7 as well as trying to combine our code for the implementation of the SearchList from team 5. We held more meetings than our usual schedule, but it was worth it since we could brainstorm ideas together instead of having to deal with slow responses over chat. The results of our project turned out quite well even with the limited time we were given to do everything. I was initially afraid of being the team leader since my first time using GitHub and GitKraken was in this class, so I didn’t feel qualified enough for the position. But as the project went on, I wasn’t as stressed about my position anymore. Every team member did the methods they were supposed to and had them done on time, so I didn’t have to be concerned with unfinished parts of the project. My members have been understanding and kind, so I wasn’t worried about asking any questions or voicing my ideas. At times when I did try to take charge and make decisions, I would make sure that everyone was okay with the idea first before moving forward. Throughout these past two projects, I have come to realize how important it is to work as a team. Without every member contributing and helping each other out, we wouldn’t be able to successfully complete each project.