Pacific Northwest Ski blog (and a few other places!)

Lots or reports from skiing around the Pacific Northwest, with some East Coast excursions thrown in for good measure

Some nice Software Architecture teaching ideas

Greg Wilson at the University of Toronto has been using my book and fellow Aussie John Reekie’s to help him teach a Software Architecture course. In his blog, he describes how he got the students in the course to compare and contrast two open source software products that on the surface do similar things (e.g. two editors, two JavaScript engines), but under the covers are built very differently indeed.

Some of the student reports are posted, and the outcomes look really positive. I’ve always suspected that open source technologies could provide a rich set of examples for teaching various aspects of software architecture and design, and Greg has demonstrated this to be possible. If I were teaching a subject like this (which I’d really like to), I’d be emulating this approach.

On a broader note, it’s a shame that architecture isn’t more widely taught, as it’s absolutely key to building successful software products. Over the years, I’ve found the lack of understanding and appreciation of architecture issues to be often alarming. In particular, when assessing the capabilities of superficially similar technologies (e.g several workflow engines, several content management systems), the ‘if it walks like a duck and sounds like a duck, it’s a duck’ principle is widely applied.

Well, I’m sorry, but in software terms, this type of thinking just doesn’t work. It might (figuratively) walk and sound like a duck, but under the feathers it’ll have a different architecture, be built to perform and scale to meet particular usages and loads, might be easy or hard to configure, manage and operate in a fail-safe manner, and so on. When people buy a car, they understand that all cars are different under the covers, and compare and contrast accordingly. Why this thinking doesn’t carry over to software technology assessment, I really don’t know?

But I suspect it has to do with the amorphous qualities of software. You can’t easily assess its design by lifting the hood and poking around. You have to dig deep and do serious analysis. Just the sort of analysis that Greg is getting his students to do in their course.

Nice work, Greg. I’d be keen to think about how we can encourage others to use such innovations in their software architecture courses.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: