The Lessons I’ve Learnt from Group Projects
Three lessons
Intro
An integral part of Software Engineering is the ability to work on a team. During my time at Flatiron School (a coding Bootcamp), I participated in many small group projects. These group projects helped me learn many important skills, however, due to the short project timelines and the immediate access to team members I had the luxury of being very informal with my project development.
This year I participated in the development of two large web apps. Both projects were managed using the Scrum Agile methodology and both projects used similar technologies. Below I wrote about the three major lessons I learned from working on these projects.
Lesson 1: Use TypeScript
Looking back, this seems so obvious. However, during our project planning phases, this was not so obvious. We had written a list of pros and cons for JavaScript and TypeScript. Ultimately, the deciding factors in choosing JavaScript were the following:
- Faster Development
- Code will be easier to understand
- Members are more familiar with JavaScript
- No Angular!!!!
We were very happy about our commitment to JS. We found ourselves developing many major functionalities in a very short amount of time and even talked about finishing the project early. We felt unstoppable.
Around the third sprint, everything came crashing down and all the “advantages” of JavaScript were disadvantages. Well all of them except the fact Angular was immediately discarded. After trying to learn Angular over the course of three days we never wanted to see that framework again.
How the Advantages were Disadvantages
The main advantage of picking JavaScript over TypeScript was supposed to be our increased speed in the development process. This proved to be true and it was going great for the first few weeks. We were able to develop many key functionalities and components in a very short amount of time.
So what is the problem with developing too fast? The problem we found was the readability of the code became significantly worse over time (this was further amplified by the fact that we did not document or comment the code). As the readability became worse our development speed drastically slowed down. We found ourselves having to spend sprints debugging code instead of finishing the project.
So what exactly made the code harder to understand? The biggest issue we found was understanding the expected inputs and outputs. Using an example from our project we had many functions that required a user argument. This would always leave me perplexed. Is user a string? Is it an object? If it is an object what attributes does it need? This meant I had to frequently read over the rest of the code to understand what is happening. If I was unable to understand (or was just being lazy) I would assume what user is and begin a debugging process. If that still did not work I would contact my group member and hope he remembers what he wrote days ago. This is an inefficient way to go about the development process.
Luckily, TypeScript provides answers to all the questions mentioned above at compile time. This means you do not have to waste your time debugging your team's working code and can focus on finishing the project on time.
Lastly, we thought using TypeScript would be difficult as we had very little experience with the language. This was the weakest excuse we had. TypeScript is JavaScript with very few differences, which should not take a long time to learn especially if you have worked with other statically typed languages just as C or Java. If you are interested in using TypeScript and don’t know where to start I recommend you check out this youtube video.
Lesson 2: Select a Scrum Master
The title for this section is “Select a Scrum Master”, but this does not mean this lesson is only applicable for teams following the Scrum Agile methodology. The point of this lesson is to assign a group member the role of managing the team.
This is an awkward point to bring up, especially when you are working with your friends, however, this is necessary.
Before assigning a group member the role of managing the team we frequently met for highly ineffective and excruciatingly long meetings. Eventually, we were forced to face the reality that this was not working. We needed someone to make the final decision and organize the team effectively to complete the project.
After selecting a Scrum Master our meetings were significantly more productive. We were able to quickly agree on the product design and functionalities but most importantly, everyone had a clear understanding of what other group members were doing. This leads me to my final lesson. Verifying teammate’s understanding.
Lesson 3: Verifying Team Understanding
This lesson was the most unexpected one of all. During meetings, I was always confused. It seemed like the components others built were not in line with what I had in mind. Eventually, I mentioned to the team that I was confused. The components that were being built were not in line with what I had in mind for the project. To my surprise, every other member was just as confused as I was.
Luckily, the confusion was very easy to solve. Doing something as simple as drawing out the user interface helped all of us get on the same page, as well as, revealed many new functionalities.
