Saturday, March 14, 2009

Episode 8 : Software Engineering

From Prof Ben's last email regarding blog posts ...

I'm assuming that my previous post with the purple dog's picture is not acceptable for grading purposes.


On Monday, Prof Ben gave a lecture regarding the Principles of Software Engineering. It's not really something too new to me, and I've heard these golden points many times over. However ... it's particularly disheartening to realize that I'm common offenders of most of them.

Subconsciously, I've known my flaws all along ... however, I just haven't had the insight or sensibility to change my programming methods. I'm always in a rush for time, and my stubborn mentality heightens the problem. Given tight deadlines, I don't think a lot before i initiate my coding. That goes for both Assignment 1, and Assignment 2.

I work for effectiveness, but paid little attention on efficiency.

This is kinda reflected in my peer reviews as well ... disheartening but true.

"More thinking, less coding"
This phrase keeps ringing in my head ever since the lecture. I was trained to be an engineer, but voluntarily side-tracked to programming and development. I self-taught most of the programming and software knowledge I know, as well as oweing to the guidance of several important people in my life. I guess I need to either shape up or ship out (which at present, is out of the question for me).

Modularity, Decomposition.
Separation of Concerns
Design for Change

I read Wenhan's post ... and I kind of agree with him... Maybe it's an engineer thing. I've heard these Principles many times over, but I can't really see the distinct boundaries separating them. To me, modularity is the mother of all principles. The rest are simply different definitions of the same logic with different methods.

In short, Divide and Conquer.

Instead of one huge gigantic block of code, the framework should be structured such that functions are neatly organized, readable, and easily modifiable. This allows for concerns (such as interface design and logic) to be easily separated and the messiness reduced. This also allows for future expansions and scalability ... just like adding lego blocks to each other. Abstraction and information hiding can also be achived, when functions, classes, and libraries are neatly and modularly planned out.

I have lots of thinking to do ... and challenges ahead as usual. I hate to admit that my codes are rather spaghetti, but I guess I'll just have to improve myself if Captain Cook were to take off to an even greater heights.

Bear in mind though, that the Principles covered during the lecture only applies to the generation of software and codes. In the real world, far more important principles need to be taken into consideration if you are to launch a successful product.

Principles such as ...

Usability of Product
Practicality of Ideas
Market Demand

And as usual ... these are stuffs that doesn't need elaboration ... coz everyone already subconsciously know what they represent, and how important they are.

The question is, why are we stubbornly not persuing it sometimes?

You can bring the cow to the water, but you can't force it to drink ...

Many times in life, the knowledge (the principles in this case) represent the water, while we are the cow. We have been convinced that the water is essential to us, but why are we just nodding in agreement without ever touching the water ourselves?

When queried, our answers in defense are usually stuffs like "no time ... i'm not good enough for that ... etc".

I think the best answer to the question, lies in our personality. We are just too stubborn or lazy to get out of our comfort zone, and then we come up with an excuse to validate or justify the present situation ... so that we become not the one to blame when things cock up because of our stubborness.

Prof Ben keeps saying that he is teaching to earn his pay ... actually that is kinda the only thing (and best thing) he can do for us. The door has been shown, noone can make you go through it other than yourself.



We are all fighting for our grades, our dreams, and our ambition. However ... somewhere in NUS Science ... a fellow student just had an additional barrier unfairly slapped in front of her before she is able to chase her dreams like us.

Please check this out, and help if you can.

God Bless.


  1. The door has been shown, noone can make you go through it other than yourself.

    Well said, but you know teaching also requires patience. I can show students the doorway to greatness and students might not get it and step through it today.... that's not a real problem ... as long as the door remains open, maybe some of you might just wise up and wander through it. :-)

    Students are often unable to appreciate what is told to them in school - but if we can plant a seed, that's sometimes good enough. :-P

  2. eventually, the most precious skill one can take away from University is the ability to learn how to learn. Unfortuantely, it may also be one of the most complex skills to realize or master.

    Often it's what's invisible within us that stops us from doing the great things we're fighting for. The visible aspects, like coding skills and design abilities, comes only as secondary importances.

    Even now i'm still trying to figure out the full wisdom of these insights.

  3. Maybe it's an engineer thing.
    haha...nod nod :P