More on the Software Engineering course
In January, I posted about the misconception some students had, where they called every method an accessor. I might let that slide when mutators are discussed, them being the other half of the get/set pair, but as it turns out, the course teacher has actually redefined an accessor to mean an instance method. Sigh.
This comes in the wake of a course that happily promotes process-oriented software development, pretends that Java is the only relevant (OO or otherwise) language out there and asserts that the role of a skilled programmer in a project is merely to choose the appropriate algorithms and then fill in the blanks after a software engineer has first modeled the system in UML and generated the stub classes from there.
The non-mandatory course book (which I, probably unlike anyone else, actually bought) is also heavy on assertions to the tune of “such and such must be done” and rather light on actual arguments on why it is so.
To me this seems like the school administrators have drank the UML kool-aid without much critical thought or real-world experience. And before anyone argues that universities shouldn’t focus on real-world so much as the theoretical side of things, I’ll add that the target and other topics discussed on the course are very much geared towards real-life software engineering.
We discussed the topic at work today, and concluded that this is a cumulative problem with a number of contributing sub-problems. First, it seems (note: this is a highly subjective view) since education is free, few students take pride in excelling at it. Second, the elementary courses leave the impression that a large part of programming (and by proxy, CS in general) is voodoo magic. Third, since students are lacking in the fundamentals, they get entirely lost in the more advanced subjects.
I admit a lot of this is conjecture based on my experience at the Open University. Whether or not the same standard applies in the real thing remains to be seen. I hope I’m wrong.