Mr. Wang and Software Engineering

No this isn’t an entry about the well-known “Mr. Wang” from blogsphere. Rather, Mr. Wang is a key fictional character in the subject I’m teaching this semester: Software Engineering.

Now how does Mr. Wang fit into this subject? Well, for the last couple of semesters now, this subject has been offered in a comparatively new instructional mode, specifically Problem-Based Learning. There’s at least one IHL in Singapore employing this learning mode en masse. Briefly, this mode of learning involves the use of realistic problems issued to student project groups, and students discover their own solutions and learning with the instructors typically facilitating only their knowledge discovery rather than doing actual teaching. Mr. Wang is a character I created as part of the central story that ties in three large problems that my student groups undertake to solve over the term.

But my entry this time isn’t about the instruction mode  but about the subject itself. It’s pretty funny, because I’ve been teaching Software Engineering for more than 12 years now but this is my first time blogging about it in a personal capacity. This was the very first subject assignment I had when I first started teaching in 1995, and in 2008, I’m still teaching the same thing. Oh, the instruction modes have changed, the institutions I’m at, and (naturally) the students too.

What’s this subject about? Well, in the most simplistic terms, it concerns itself with the study and employment of traditional ‘engineering’ principles in software development. Now that statement may not mean much, but if one tracks the evolution of software development in itself, that statement says a lot. Specifically, one of the analogies I’ve used in every one of my lecture groups over the years is this: if you received your first software programming assignment, then sat on a toilet bowl and starting writing code on your notebook, you’re at some level engaging in software development.

But that isn’t software engineering. You’re only said to be engineering software if you went about developing that software in a specific manner i.e. by using principles, ideas, and best practices that have its roots in engineering that’s developed over hundreds if not thousands of years. Friz Bauer, an exponent of the subject writes that:

Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

This definition is included in Roger S. Pressman’s book, one of the key reference books for students anywhere studying the subject.

Some examples of these principles: e.g. the idea that before you create a product, you’d best properly specify what is it you’re creating first. Or when you’ve finished creating the thing, you should evaluate that product against that specification you created at the start.

Now, all these ideas may seem a natural part of software development, but they weren’t always. And more importantly, these ideas didn’t stem from our understanding of software. It’s been with us for ages, long before software first came about.

Unfortunately, the subject isn’t easy to teach. I remember at one point in another institution I was lecturing at, Software Engineering was the most dreaded subject among academic staff. The complaints were usually the same. “The material’s dry and difficult to engage students with.” Naturally that sort of difficulty staff wrestle with occasionally affects student learning i.e. if the instructor finds it dry, how will students not find it the same?

Ironically, I like teaching this subject. It’s a challenge of course. But one advice I’ve given to new staff routinely assigned to my teaching teams is this: the trick is to ground in the real world and common sense every one of these software creation principles. E.g. one analogy I use. Why does it make sense to employ software metrics? Well, the idea isn’t unique in software creation. We use metrics in just about everything else we do, including looking for potential life partners! That always perks my students up.