This is not a post ranting about the pace of the class (like it’s too fast etc, like I mean all of us chose this module right?), but rather, talking about how it could reflect actual project deadlines and schedules in the real world.
So one of my bigger motivations for taking this class, apart from my interest in CS and building cool stuff in general, is to build cool stuff that will make an impact to society.
Given the above premise, it is assumed that we have to settle on our best idea before we can start building anything. However, given the time constraint of this class, all of this is not very possible – after brainstorming and looking at pain points, even if you don’t think your idea can solve cancer (exaggeration), you are forced to START BUILDING.
Which may not necessarily be a bad thing. Well, for one, real world deadlines are inflexible and have no end, and as a future software engineer or entrepreneur, there’s usually no way to negotiate around this (so you probably have to build as you plan). And you do get better at it as you do more of it. It’s kinda like how they advocate not “waterfalling”, but to take small steps and iterate.
What i say above dosen’t mean that I advocate poor planning in projects, and a “just whack” attitude. To clarify, having experienced pivoting the business idea (and hence a huge part) of a project midway during assignment 1, I feel that what’s important is to still have a solid business idea and prototype to ensure everyone’s on the same page, but also to settle on the best ideas if you do not have long enough to think of better ones. I guess there’s always a time trade off in everything, and as a member of a team in any project, one should be aware of this and weigh the tradeoffs and know how to be effective in driving the project forward towards it’s goal