I was in a meeting just this morning regarding how we measure the performance of something which ended up with reading a paper on queue theory to help with the design. CS and SE are very related. Also, Civil Engineers do learn physics as part of their course.
> Also, Civil Engineers do learn physics as part of their course.
The analogy is apt for exactly that reason. Some knowledge in physics is fundamentally required, but for the civil engineer it's only professionally relevant to the extent that they can apply it to solve practical problems. A solid understanding of physics (and indeed how to come out wiser after reading a paper relevant to your field) is just one part of their expected skill set.
What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years and couldn't be covered in a module? I have thought about this before and argued for Software Engineering to be a specific course/field, but it's just too ephemeral at the moment with a lack of 'core' elements to warrant a 3 year course.
Edit: To be clear, I want the field to mature and develop into something similar to other engineering fields like EE, but it's not there yet.
> What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years and couldn't be covered in a module?
Requirements management, information security, software architecture, all the big picture topics that are applied and not theoretical in nature.
I took a module in my MSc in CS on these topics and they were boring, out of date, and things you learn as you need on the job anyway (I took a part-time MSc while working). They were also covered in just two modules.
Sure, some courses could be up-to date but ultimately they'll be out of date in a couple years. Core concepts like OO are a bit more stable but you can be taught this in an applied sense or a theoretical sense and both are covered in a good CS course anyway.
> What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years
Industrial economy, ethics, engineering professionalism, development methodology seem rather universal. Then, depending on specialization you could pick up anything from signal theory to control engineering to human anatomy.
> and couldn't be covered in a module?
That's a pair of very, very narrowly placed goalposts. Of course you could cover anything in a module and call it computer science, but where would you go then if you have a legitimate interest in computer science and not a bunch of courses that really have nothing to do with it?
Some software engineering studies, even sometimes called information technology (Australia, Netherlands, Germany) are theoretically equivalent to most of the general CS studies you find in the United States. It all depends on the curriculum at the end of the day.
I'd like to see them have to go into a million-line code base, find the right place, and add some new functionality. They'd learn a lot about the importance of good organization, naming conventions, and leaving pointers for the people who come after you - things they never would have learned in a lecture, or by working on 1000-line programs.
I agree. I think there is a definite need for real 'Software Engineering' discipline that focuses on things like project estimations, timelines, codebase management, best practices, etc.
Absolutely! Some companies are great at this but most (from my experience) use the term but there's 0 'engineering' involved - it's just hacking bits of code together and hoping it lives long enough for a customer to sign off on UAT. There was a good talk on this subject last week - here's the recording if you're interested https://youtu.be/3018ABlET1Y
