Assignment 1 was due two days ago and it has been a whirlwind ride for NUSHello. I think it isn’t very polished and given the sufficient time period, we could’ve done much much better.
One of the lessons learnt from my previous internship was that engineers don’t panic. This advice stuck with me a lot for this semester and it removed that panic attack that I used to get when things don’t go according to plan. However I think this exact advice led me to believe that things are going to be okay when they clearly aren’t. Colin’s comment for both of our app review was that we will fail. Not to say that we didn’t take his advice seriously, but we didn’t know how we could prevent that or improve from it.
Shit also hit the roof when one of our team members dropped the module.
During the last few days before the deadline, I had to tell myself that I don’t build shit products to tide me through the nights. So at least now the product isn’t outright shit.
Here are some of the lessons learnt from it:
Do the mock-ups and wireframes well.
We didn’t really put a lot of effort in the mockups and wireframes so they were not really well done. We only came out with the standard layout of the application of how each page should look like and did not put much thought in the app flow.
The mockups were done more as a way of telling us “okay this is what the page needs” and we left it there without any iteration. None of us touched or looked at the mock ups until the final week and wondered why didn’t we improve on crucial areas, and also how the application flowed.
Frontend development should not wait
Another major mistake we made was waiting for the backend to be set up properly before we began with real frontend work. What we should have done would be to mock the objects from the backend such that both development can go on concurrently. We realized this too late into the project and of course this was due to some severe miscommunication.
What this meant? We did not have sufficient time to iterate on usability and UI/UX improvements. Zero user testing was done and we failed the app review twice because the application simply didn’t work.
Choosing the right tech stack
I believe I’ve written enough on how our tech stack was a total disaster despite choosing all the latest and exciting technologies to use. None of us was that familiar with any of what we’re using so at the end of the day we are all as confused as anyone else in the team.
Productivity was really affected by this, and so was the team morale. I think many of us didn’t feel happy working on this project since sometimes the project was really heading nowhere.
In conclusion, I feel that the idea was fine, but the execution was done poorly. Given another chance to make this right, I would certainly do this all over again. (Who says we cannot still continue work on this during our free time, right?)
Colin’s comment on my previous blog post really stuck with me.
Live and learn.
Here’s hoping I’ll do the two final app projects better after having the experiences gained from assignment 1.
I briefly mentioned before about my experiences with messy PHP code and really messy code architecture. Maybe I’m seeing it for myself right now how difficult it is to set up a code architecture that makes sense. Cloning right off someone else’s project as a base isn’t the right thing to do most of the time. It requires us to fully understand the architecture before implementing it ourselves.
Just to take note for future projects.