After a whole semester of non-stop struggling, CS3216 had at last come to an end. Now that things had calmed down somewhat, I think it’s good to reflect on why I had struggled.
Assignment 1
For the most part of assignment one, I think my main struggle was to figure out nodeJS and Squelize. During the second lecture, when Prof Ben advised rather straight forwardly that we should just use a framework we’re familiar with, I gave a nervous smile. Me group and I are already halfway into a framework i have never ever touched before. The prof was right of course; if even then had we switched to a more familiar framework we might actually had gotten done slightly a bit more then what we eventually had.
I guess the idea was this: choosing the right tool for the job is not the simple task of looking at the problem picking out the best tool for it. One should also consider the skills of the team one has and how much they can achieve within that time period. Sometimes, a tool might not be the absolute best given the problem, but one the timeline is take into account, it might be the best choice.
Assignment 2
Assignment 2’s stuggle was…. jk A2 was easy. Complaining about other apps is easy as cake.
Assignment 3
Looking back, the hardest part about assignment 3 was that we tried to push the boundary of tech a bit too far. When our app is up, it basically turns on every other sensor in your phone. Best part was that it depends on everyone one of them to work. When one fails, everything fails. One of my friend’s had a phone with a wonky GPS, the app didn’t work. Another friend’s gyroscope was weird, the app didn’t work either. Then, we had Apple who won’t let us get the camera, the app didn’t work either.
The idea was born out of a brainstorming session. The method was to list down everything we have in a PWA and see what we can use. In the end, we just combined everything and the project was born. I would say now that when an idea depends totally on a whole bunch of tech to work flawlessly, one should really tread carefully before declaring it a viable idea, no matter how possible it seems when it was dreamt up.
Final Project
Given that I had been ranting quite a bit on what went wrong for my final project, I think i just have one last thing to say. When doing a project in a impossibly short period of time, think about what it is really that you are trying to sell to your users. Everything you decide to sink some time into must contribute to that goal one way or another. Beyond that, what the user wouldn’t be seeing, he’ll never see anyway.
My final project was a patchwork of many parts scrambled together, but thanks to the abundant guidance we’ve received, they could make up a coherent story in the end on steps day.
Conclusion
The 80-20 rule seem to apply to so many things. Let me add one more to the list: 80% of the selling point in a app comes from 20% of the features. Spend time to make the other 80% up to scratch, but make those 20% kick ass.