A peek into the past…

I never wrote many of the weekly blogs as Prof. Ben had asked us to. I’m tempted to blame it on the ‘lack of time’ and take the easy way out. But the truth is that I was never really a good writer, and never seemed to convey all my thoughts properly through my writing. So I always tried to avoid writing as much as I could. But one of my most memorable semesters is just about to get over and I could find no rationale in still hanging on to my childish complex. So I decided to just go ahead and express some of my views through this blog entry.

It has been a very tiring and quick semester, mostly because of 3216. When I first applied to this module, I thought it would be a very technically challenging module and would help improve my coding skills much more.  Although I was very enthusiastic while applying, I was pretty surprised and slightly afraid when I actually got through. I was then thinking that this module required elite coding skills, and being from Electrical Engineering that was something which I didn’t have. But I still decided to give it a try and was hoping for at least a pass grade in the end.  And that was basically how my 3216 journey started, filled with excitement and fear. How it turned out is a completely different story though!

To be frank, our final project was a mess when we started it. The backend was slow, the UI was bad, nothing seemed to work, we kept missing our project deadlines and Prof. Ben was continuously on our back. But I think with every failure, we got slightly better. The amount we screwed up kept shrinking with each submission. In the end, we were able to change our app’s whole design with a new name and a new theme in just about 35 hours before the poster session.  From a place where I was taking three days just to code a single API call, to a place where I could redesign the whole backend structure in about 30 hours, I’m proud to say that I’ve come a long way technically.

But more than the technical stuff, there are a few more interesting things that I would like to talk about based on my experience in this past 4 months.

• Good backend doesn’t mean good UI. Good UI doesn’t mean it looks beautiful. UI looking beautiful doesn’t mean that it is easy to use. And to complete this vicious circle, being easy to use doesn’t mean that everything works the way it should.
• We were building a productivity app for our final project and some people didn’t face the problem that we were trying to solve. They continuously criticised our ideas and efforts. But in the end, I learnt that there is no such thing as everyone loving a productivity app simply because everyone doesn’t need it. Criticism from someone not facing the problem can be ignored, whereas criticism from users who could relate to our problem is very vital.
• Making an app without continuous user feedback is like building a rocket without knowing about the atmosphere. If you are very lucky you might have built the right model and your rocket might not even get scratched. But for our rocket, it more or less just exploded.  After this explosion, all our other iterations went through a lot of user feedback on UI, purpose, solution, etc., and our rocket then grew more stable.
• There is no such thing as a perfect version for any app. We made around four complete iterations for our final project. With each new iteration many problems got solved, but we kept finding ourselves in new and more complex problems. An app’s improvement cycle is an endless road. You can never solve a problem perfectly because there always is a better solution. What makes the difference is, if you are able to reach that better solution faster than the others.
• The existence of a mammoth competitor app doesn’t mean that your app will fail. It just means that you need to look beyond the competitor’s perspective, and try to reach that better solution before they do.
• A good team comprises of elite programmers and elite designers. But a great team consists of people who are willing to shun their ego and would go to any lengths, just so that the app solves the problem even slightly better than it previously did.
• Building an awesome app just solves 20% of the problem you are trying to solve. The rest 80% is how you actually take your app to the people who face that problem and make them use it. And this 80% is the most difficult part, as no one teaches you how to do it right. Everyone just shares their marketing experience. Just blindly following them doesn’t mean that it would work the same way for you too.
• You are your first and best critique, because only you know what exactly you were trying to solve. After building the app, if you don’t see yourself using the app for the purpose you created it for, then it surely means that the current version is a failure. It’s time to go back to the drawing boards to iterate.
• A ‘cool’ feature may not always be the ‘best’ feature. We tried to introduce features like ‘content aware swiping’ and ‘long touch movement’ in a web app. We were really proud of ourselves at first. But users are accustomed to a particular way of browsing their web apps. In the end, our ‘cool’ features ended up confusing our users and hindered even the normal processes. So of course, we had to remove them in the next iteration
• Programmers under estimating the time that they need by half, is a fact. But unfortunately this is true only when you are working on something that you already know what the hell to do. If working on something you don’t have the slightest clue about, please multiply the time you ‘think you need’ by at least 10 to even come close to the actual time it takes. This had a deep impact on all our deadlines. We usually submitted everything late. But then I learnt that working with ‘micro-deadlines’, made things much better. Logically, it might not reduce the total time needed to complete the code. But completing micro-deadlines at smaller time intervals means that you are able to conquer more deadlines within less time, thereby increasing your morale. And a good morale is what keeps your patience going  when you are searching through pages and pages of google results to learn something that you don’t have the slightest clue about.

 

NUS to me, is not about learning how to succeed. It is about experiencing more and more failure and that is what happened to me in 3216. For only a person who has experienced failure, would realise that success never lasts long. And only a person who realises that, would know that failure never lasts long too.

These were just a few of things that I remember as I write this blog. This is just my perspective based on my experience, although tomorrow might be a new day with new perspectives. That is what makes life interesting to me.. looking forward to the next day, completely uncertain of what I’m going to learn or experience!

I belong to the reserved bunch in class and was never really very vocal. But I’d like use this post to thank Prof. Ben for 3216 and for giving me the opportunity to be a part of it. It really took my NUS Experience to the next level. Until now I was basking in the safety of the NUS compound, whereas Prof.Ben guided me near the wall and helped me jump and take a peek at the world outside.

Another person that I would like to thank is Kok Wee. I look at him as the ‘silent mastermind’ behind 3216. I’m pretty sure he is technically very sound. But when our first project report bombed and we had to have a special meeting with him, I think his guidance and humility were the main driving force that put us on the right track.

It has been my pleasure, an honour actually to have been part of this module. Prof. Ben asked this question first about whether we were a lone nut or not. I had a confusion of who exactly I was, back then. But now I know. I am a lone nut.. have always been one and will always be one too!