Sometimes I hate academics because they are too busy to define some cryptic academic-only idioms (hello, fault-failure-error!) instead of fixing the real problem: our code suck. Keep in mind that it’s not entirely their fault. It’s the fault of the system and tradition, but that’s for another rant. Today’s rant is on how they focused on the non-construction side of software engineering when teaching about it.
For example, software quality. Today’s software quality mostly focus on two things: the quality of software building process (Software Quality Assurance) and the quality of the resulting software (Software Quality). Both is, of course, important but the problem arises when the focus on improving quality moves from improving code quality to a more bureucratic way: adding more and more layers to the software development process.
If you want to produce a good quality software, make sure your code don’t suck. If you want to make a code that don’t suck, make sure that everyone have lots of experience in writing code. That’s the only way to be a good software engineer, IMO. Remember: you can build a software without requirement engineering, design, test, etc but you definitely can’t build a software without coding (construction).
You need to improve your construction skills first, then learn about requirement, design, testing, etc. Not the other way around.
Not to say that other part of software engineering is not important (they definitely are), just that we need to make sure that we understand construction first, then the other. Unless you want to become the bureaucratic software engineer or architecture astrounout, of course.
In my (ideal) academic world for software engineering, we will teach the students to code, code, and code for 3 straight years first, and then give them some insight about design, and all the other software engineering topics. Because let’s face it, 3 years is still not enough to learn proper coding. Of course, most of their project will be a team project, sometimes with a more than 10 people. This will effectively teach them about bug tracking, version control, and all that other software that’s used in the real world.
The lecturer, of course, will need a really, really great experience on building software. But how? I say we let them build. Tell your lecturer to build an OS, or a MMO Game. Or other thing that is a real challange on software engineering. Not some half-ass research software. This kind of project will not be approved, of course. I can understand why, and that’s why I hate the system.
Maybe one day the system will change. A man can dream.
Alas, this is a random rants that’s written in 15 minutes. Sorry if there’s no structure on this post, and maybe some grammatical errors. Please point it out to me if I make some mistakes.
Thank you for reading.comments powered by Disqus