Software Engineering (From a designer's point of view)

Alrighty! I'm back!! I've been in this "don't want to blog" mode, partially cos i really don't like to blog for the sake of blogging. Haha, i feel that blogging should be a free flow of expression, and can't really be mandatory else it'll be real boring. hah..

I do need to apologise to prof Ben for monday's gloomy face. I know how hard it is to present in front of a unresponsive class, but it really wasn't your lecture that was the cause - i have been sick for the past few days (the almost sick but not there kind) and yeah, i had a really bad test on monday :S So yah, that's why the sian diao face.. But your lecture was really good! :D

Anyway, wanted to play cheat and do a combo of the last 2 lectures (my penalty lecture and prof's software engineering lecture), but the post for the last lecture alone drained quite a bit out of me.. merh. Prof, i'll make up the penalty lecture another time! :P

Anyway, i've tried to make this summary as entertaining as possible so i hope all of you out there will enjoy it :P So starting with prof's lecture.. I must say, prof, that you can present damn well. haha! I got several nice takeaways from it, but here's the one i like most:

VS

Presenting... The Agile Iterative process VS the SDLC Method! haha.. i felt it was a very interesting model.. it was precisely what Janus was trying to get our group to do for our WPF project. Implementing this process is a huge challenge tho, cos it really takes a lot to 'know when to stop'. I believe the 'curse' that lies with me and many people is the want to implement more, implement all at one shot. But personally i do feel this process is good - it allows you to visually see what's happening, and also let other people who are in on the process see the app slowly build up. I suppose the frustrating and dangerous part lies in having to redo the app over and over again, which is a good thing cos it makes you continually seek improvement, but is dangerous cos the reluctance to change everything (and bear in mind this requires motivating a whole team, not just a person) might simply cause the improvements to grind to a halt.

I'd love to see this process in action though, and see how zihan's team actually managed to pull it off! It would have been amazing (apart from the fact where i won't really be able to tell what the programmers are doing :P)

So prof Ben basically covered 5 principles in the lecture:

Principle #1 Abstraction

Close your eyes and imagine some things don't exist. Like your homework peeking out from your overflowing bag. Or your those emails by prof ben telling you to pass up your group proposal. Wouldn't the world be just so much simpler? Same thing for your design. Just hide everything that's not important, and clean up the interface/app design. Let your user focus on only the most important things at one time.

Principle #2 - Separation of concerns

Like a damn good shot of B-52, you gotta separate the layers to taste each section in all its smooth flavour. Mess it up and you've got one hell of a lousy shot! So guys, remember to keep the layers clean and defined! :P

Principle #3 Modularity and decomposition

The first thing that comes to mind when you hear modularity - LEGO. And it describes modularity perfectly! Basically, prof ben summarised it in three main points:
- Break it down to liddle bids so you know who's head you can chop (if one part of the lego collapses.)
- Make sure it can talk to one another! Don't get a 2 point adapter for a 3 point plug!
- "High cohesion, low coupling" Let it be a 'standalone' yet an integrated part of the big picture, just like lego bits are all one standalone piece that can be pieced firmly together. And while looking for lego i found this damn cool modular product (sorry, the ID side of me at work :P) By the company Bug Labs,

"BUG is a collection of easy-to-use, open source hardware modules, each capable of producing one or more Web services. These modules snap together physically and the services connect together logically to enable users to easily build, program and share innovative devices and applications. With BUG, we don’t define the final products - you do."

Super cool product, no? So now you have the LEGO computer! Want an extra gb of ram? snap it in! Want am LCD screen? There you have it! How about a speaker? And the list goes on and on.. But the BEST part is that BUG can be upgraded and scalable. Which means you can probably be using the same product 10 years down the road! (this does mean bad news for the marketing peeps tho - imagine having no one to sell to cos you're still using the same product from 10 years back? >.<) haha. So yes, lesson to take away - make it standalone, make it fit.

Principle #4 Generality

So if you haven't already realised, the picture above is a skeleton key.

*waits for laughter, receives none* -.-

Anyway, that's basically what generality is about - to solve many problems in one go, like how one skeleton key can open many locks. Erm, the part about cutting, pasting and editing code i roughly understand only, but eh, you non-coders get my key analogy right? okay! so let's leave the coding to the pros! :P haha..

Principle #5 Design for change

This is the part where my favourite SDLC and Agile iterative process was brought up. :D I like. But yeah, what design for change basically is is to plan for change, to build in that freedom to allow your app to grow. Just like the inchworm shoe:
You know how little kids grow out of their stuff real fast? Well, with an inchworm shoe, your kid (referring to prof ben, the rest of us are still currently non-applicable) can have a better fitting shoe up to three sizes larger! And knowing how kiasu singaporeans are, they're probably gonna buy it one size too big anyway so that makes it 4 sizes! :P Not bad huh?

So after all that, what is Software Engineering? It's basically the management of complexity to reduce bugs (which i'm infamous for creating :P).

And because of that, prof had 3 of our dearest classmates, Mannie, Justin and Zihan (well one lao da) to present on how they've managed projects :D I can't sum up the richness of their experience, but i can say that the methods really inspired and intrigued me :)

Stuff that i learnt and stuff to ruminate on?
(i'm gonna list it in just small points for my own keepsake)
- From Mannie: Scrum - the naggy technique to chase people for work
- From Justin: Prioritising, the breaking down of tasks to simple achievables, subscribing manhours, cutting features, who does what and when and how?
- From Zihan: Document like crazy! Be super duper organised! (TRAC)
- Why can't programming be a simple language? Or is it because it's just another super defined language? (like hebrew :P)
- Outsourcing - it's not happening? But it's a growing trend? Why?
- Separation of UI from business logic

So that sums up our Monday's lecture! Key thing to remember?

"Think more, code less!"

Random ramblings and thoughts that occurred while writing this blog:
One of my greatest regrets is having khoa as the single programmer in our team. Perhaps if he saw many other brilliant programming styles in action, he would have the chance to be inspired :P Just like how i can't survive alone doing design.. other people's designs are constantly influencing me, pushing me to get better (like mannie's drawings!)