12/06 - CSCB07 Final Project, a retrospective.
On 12/02 me and three of my CSCB07 teammates handed in our project, a testament of over a month of hard work, held together by bubble gum and bandaids. For me, it was a pretty crazy rollercoaster. Initially super chill and confident, turned into a last minute scramble. In this article, I intend to go through this in a retrospective, analyzing my mistakes and things I could have done better.
1. I setup the GitHub poorly, I should have put more thought into it
2. I should have been more careful setting up the Android Studio Project
3. I should have tried to think in simpler terms
4. I should have taken more advantage of provided resources
5. I should have been more proactive
6. I should have done a lot more planning between the backend and front
1. I setup the GitHub poorly, I should have put more thought into it
I should have put more thought into setting up the GitHub. Something that didn't fly through my mind when setting up the repository is the fact that the Android project contains alot more than .java and .xml files. If I was thinking straight, I should have created a blank Android project, pushed that to main, then tell my group members to branch from that. This would have saved everyone a lot of time and me a lot of headaches. Because we did not do this, merging our work together was to put it mildly, a nightmare. The config files were NOT very forgiving.
2. I should have been more careful setting up the Android Studio Project
Because Google is behind Android, and thus Android Studio, everything goes the way that they want. From what I can tell, Google is pushing for Kotlin to eventually replace Java as the standard software development language for Android. As such, when you choose one of the provided templates in Android Studio, your project will automatically be configured to use Kotlin. The only way to work around this is iirc to choose "Blank Project", which will then give you the option to pick either Java or Kotlin. This somewhat ties into part 1, Furthermore, there is also the Kotlin vs Groovy thing for the Gradle scripts. I should have sought extra clarification for which to use, because the example application used Kotlin DSL, but all the resource videos used Groovy.
3. I should have tried to think in simpler terms
Once I get going, I quite literally cannot stop until someone physically stops and slaps me. Once I start building that broken building, I will keep building, adding more layers and more support, no matter how impractical everything is. One of the intricacies that I built was a sort of listener method that I used to communicate between the View and the Presenter. This was completely unnecessary, and made the program more bloated. Instead, it is much easier (and much simpler) to just have the View as an object in a field in the Presenter, and whenever the Model has returned its data and the Presenter has done whatever processing it requires. There is for sure even more, but this is the most memorable one for me.
4. I should have taken more advantage of provided resources
The teaching team had truly provided a plethora of office hours, extra resources, etc. I should have consulted these more, it would have saved me a lot of time and it would have made the project easier/better. One of the most memorable issues I had was getting Mockito to work. I spent atleast 12+ hours trying to get it working when it was really inconvenient to be slowed down by such an issue. Scouring the internet, mostly over Stackoverflow, was super unhelpful and nothing I tried worked. It was only once one of my group members went to office hours did we finally get the issue solved.
5. I should have been more proactive
Our team was pretty disconnected. Even though we had three meetings per week and were in constant contact over Discord, we were still extremely distant. One of these issues was that we didn't set any sort of standards. As a consequence, our code is pretty disorganized, there is a ton of redundancy. Furthermore, merging our code was also pretty hard, as it was really unclear what everything did, and it took a lot longer than expected. Because no one else in my group really looked like they wanted to take this role, I should have been more proactive in setting standards and overviewing everyones progress and work.
6. I should have done a lot more planning between the backend and frontend
One thing I regret thinking, now in hindsight, is that the backend and frontend can be completely developed in isolation, and when both are completed, we can simply just merge everything together. This was a really bad plan. These two should not be developed in isolation. Before the beginning of each sprint, I should have done a further meeting with the individual writing the frontend to discuss what was needed for both the frontend and the backend. Because we had developed everything in isolation, we both found out that we had made things that were unnecessary/did not implement. In our extra meeting, we should have discussed our vision for what the program looks like and set everything in stone (not literally, with any changes we notify each other to figure out how to work everything out).
I meant to have this article out a lot earlier, but exams got the better of me so I am releasing this article over 12 days later, but better than never I suppose.
Josh