Should top CS schools offer Software Engineering as a separate major?
nerdcollider.com
nerdcollider.com
Just as in CS/SE, EE has a wide range of topics, from the very practical ("how do we organize a team to build this") to the very theoretical (quantum mechanics, nonlinear control systems, signal processing). Yet somehow, no one in the EE industry is lobbying for two separate majors (I know; I work in it).
In EE, it is just accepted that you just need a theoretical background to be a top circuit designer. This isn't really open to argument: the best ideas and the best designs are almost always the result of careful analysis and deep understanding of the underlying phenomena. When I interview someone, I'd much rather know how well they understand control theory than how well they can throw together yet another folded cascode. (I'm sure there are exceptions to this rule, but frankly I have yet to meet one.)
Most good EE departments naturally have a few separate tracks that you can follow as an EE. For example, at MIT, the EE headers are circuits (6.012), signal processing (6.011), E&M (6.013/6.014), and bioelectrical (6.021). You had to do some work in each, but everyone generally gravitated towards one or two of them. As a result, people who want to do hard core device physics can take a very different set of classes from those who want to design microprocessors.
At MIT, the same model applies in the CS department. There, the headers are 6.033 (computer systems engineering), 6.034 (AI), and 6.046 (algorithms), and under each there are vastly different topics offered, from compilers to classes basically indistinguishable from pure mathematics :). As a result, I don't feel at all like my CS education was too theoretical: I was able to choose a somewhat more practical path.
Given my experience, I hold with those who favor the ability to diversify in accordance with one's interests. It has served me well, anyhow.
For example, as someone interested in going into AI research, the main things I wanted to add onto a PLs/theory/algorithms CS core when I was an undergrad were statistics and philosophy, plus a bit of (computational) linguistics and cognitive science. A rigorous grounding in advanced statistics, in particular, is becoming indispensable in some areas, especially as portions of the statistics field are actually migrating into CS departments (machine-learning and data-mining type stuff).
Within the confines of a 4-year program, I took basically no software engineering, and relatively little low-level systems/compilers/architecture stuff, to free up room for that other stuff. Other people chose differently, but I don't see any reasonable way to fit in all the relevant stuff in 4 years (for example, the people who took all the architecture/OS/systems classes typically didn't take more than one intro statistics course).
I doubt any engineer or scientist with a remotely interesting job is in a position where they knew everything they'd ever need coming out of college. In the end, the most important experience you should get out of college is how to teach yourself more stuff later.
It's obviously going to depend on the school, but my experience was also that EE does a better job of balancing theory and practice. There's a better sense of what constitutes foundational theory in EE than CS. Every EE program is going to have basic sciences, circuit theory, E&M, signals, control, etc. Beyond basic data structures and algorithmics, you can find almost anything in a CS curriculum.
On the practical side, CS professors typically have less experience in industry than in EE. The vast majority of professors in the engineering faculty at my university are professional engineers, which requires at least a couple of years of practical engineering work.
One point I will give CS, though - CS students typically get far more design experience than engineers. EE has a lot of emphasis on problem sets and lab exercises, whereas CS students are usually designing their own programs from the first day.
UT places CS under the Natural Sciences, and indeed I have spent the lion's share of my 3 years here studying algorithms, discrete math, and numerous levels of predicate logic.
At A&M, however, the focus was on engineering robust software, using theory where applicable (straight from Dr Stroustrup's mouth during a lecture, actually, and his views were widely accepted among the faculty I spoke with). CS is under the Engineering School there, and they felt that was where it belongs.
I think part of the issues is semantics. A&M CS is not known as a prestigious department, but their engineering college as a whole is; they might see it as an admission of inferiority to be "merely" the practical side of things. However, what they do is not inferior (even if it's not what I want to study): it's the other side of the coin, but they want the department to be just as well known so they use an improper term to catch attention. I think they have a great opportunity here to differentiate their offerings and start the trend if they would just call it the Department of Software Engineering to complement their well-known Petroleum, Electrical, Computer, Nuclear, Mechanical, Civic, etc offerings.
[edit: apologies for poor articulation and verbosity. resolved wontfix].
Some theory may not be practical, but learning to think the way theorists think is very, very practical. And a lot of fun.
That all said, I do believe some software engineering concepts should be taught as part of the CS degree. If you do go work for a large engineering company (Boeing for me), then being exposed to different development processes is helpful. However I can't say this enough, at least here at a large company, you can see a difference between someone with a solid understanding of cs theory and someone that does not.
The SWE program in my school was basically CMPE minus all the hard EE courses. And while I can see there being an argument for not requiring SWE students to know advanced fields / waves etc. It's been my experience anyway that SWE students seem to not get enough of the common engineering knowledge that the other departments share. (again in Canada)
Anyway, just my 2 cents.
http://news.ycombinator.com/item?id=968013
http://news.ycombinator.com/item?id=1131606
http://news.ycombinator.com/item?id=690798
People who do systems research don't do much with theory and formalisms, but they are decidedly doing computer science.
Here, you can choose either Computer Science at the exact sciences university or Informatic/Systems Engineering at the engineering university.
Both offer courses on algorithms, discrete mathemathics, and such. The thing is that to earn an engineering degree, you must sit for advanced physics, chemistry, economics and other complementary studies.
I don't have a super-deep understanding of all these fields (who could?) but it's enough to give me quite an advantage over some of my colleagues. And I always thought they were worthless at the time.
SE is unabashedly about software and the process of developing it. It's about design patterns, how to manage software projects, testing and verification, etc. I just looked over my school's latest curriculum and it looks like they've added electives on embedded, real-time and distributed systems.
CS is, well, CS. The software is just a means to an end. I was a CS major, and prefer it that way.
My issue with SE degrees in general is that we don't have the decades (or centuries) of process experience that other engineering disciplines (mech, civil, EE) have. Agile? Waterfall? Pair programming? OOP? TDD? We're still figuring out best practices in software.
There is a noticeable lack of rigor in most software projects, but that is correlated with software being incredibly hard to get 'right', as opposed to a bridge or other fixed piece of critical infrastructure.
True, but is an academic setting (especially a university) the right place for such a curriculum? What languages, platforms, testing methodologies, coding practices, etc. do they choose to teach? Do they try to teach things that will get their graduates jobs at Fortune 500 enterprises, or cater more toward the local/regional offerings? What about the start-up world, where you're almost guaranteed to be using a large number of cutting edge technologies that you probably won't have used before you got the job?
The thing with CS, at least as it's taught at my university and the several others I looked into, is largely concerned with making sure the students understand theory. It doesn't matter a whole lot what programming languages or textbooks they choose to use, because the assumption is made that when you get a job, you're going to have to learn the ins and outs of that particular job no matter how much you learned about specific software engineering practices in class.
This is why I wouldn't even want to study "software engineering" over "computer science," unless I knew exactly where I wanted to live and who I wanted to work for and thought the particular SE program would prepare me directly for that specific job.
All attempts to establish best "engineering practices" in programming have so far been resulting in incredibly messy and inefficient technologies. UML, Corba, Object Oriented programming -- just to mention a few.
Also, whatever comes from an academic institution, as a rule, doesn't pass the reality check until it get stress-tested by the industry. Professors who don't build real-life software systems, can't tech engineering by definition -- they should stick mainly to theory.
Until programming matures, CS algorithms and data structures should remain our nails and wood.
But that's not only what SE about. It's also about taking all the various algos, data structures and design patterns in a system, and pulling them together on time, on spec and on budget. SE is a discipline of process, not of theory or algorithmic correctness.
But you're right in that most SE 'best practices', as they teach them in school, are sorely lacking.
Unfortunately, no-one has yet worked out how to do that reliably and repeatably, which is why "software engineering" isn't.
Then again, "computer science" isn't either.
If we're going to have a sensible discussion about splitting theoretical/mathematical courses from practical/applied ones, perhaps we should start by completely removing the misleading terms CS and SE from the debate.
I think students have enough freedom to mold their own strengths and passions into the CS program here.
There was a two semester final year course that students had to take. In this course, project teams had to design and implement a software system for a local business or organization. While I had my own concerns about the formal curriculum, I always thought this capstone project was very good experience.
I was a Math/CS graduate, but ended up being part of the pilot for the program. I spent a semester plus a summer internship working for a local company dealing with integrating GPS tracking of public transportation systems. It was a cool hands on experience for what was then (2000) an emerging tech area.
CS and SWE are really quite different disciplines, as much as say Math is from Physics...perhaps a better analogy is Physics and Civil Engineering.
I really am not sure about this. Software Engineering really is the process or craft of creating software. Computer Science is the theory behind how computers work. A good SE program should really be teaching more topics on top of a good CS program, because a good theory base can make a huge difference in creating good software.
The main problem is that Software Engineering, as a vocation, is just too large to really be taught. A developer that works in scripting languages only doesn't really need to be concerned about specific architectures or even most data structures because they don't really use them. However, a kernel developer needs to know all of that, and be extremely proficient in using those topics for their work.
So while a Civil Engineer only needs a subset of all the Physics topics, it's not really possible to do the same with CS and SE.
Civil engineering is quite different from EE or CE in the same sort of ways. Sure there's some overlap, but they are different disciplines.
I'm afraid that schools that haven't even thought about differentiating CS from SE at this date are really doing themselves a disservice and in my opinion shows how little the faculty understands about the applied arts and crafts of modern computing.
Again, in my opinion, it's shocking to me every time I hear of a school that doesn't differentiate these disciplines. It's like lumping accounting and math into the same major because "it's all numbers anyway".
Of course, much of computer science is not very useful for computer scientists either! Today if I want to study programming languages, I might need to take a qualifying exam in machine learning -- this particular combination of subjects surely is just a historical accident. I think CS as a whole might be better off by splintering a bit. Alan Kay observed [http://markmail.org/message/vsnhl7l6igpess65] that UCLA has 1 computer science department but 25 biology departments! CMU has one "school of computer science", which includes the department of computer science, institute for software research (SE), machine learning department, etc -- that seems really nice!
If degrees in Software Engineering do become more popular, I think many students who want to become programmers would still choose a Computer Science degree instead, because the two fields tend to stress different aspects of ideal software development: mathematical elegance versus well-managed teamwork. And there are still more ideas: see Richard Gabriel's proposal Master of Fine Arts in Software [http://www.dreamsongs.com/Files/MFASoftware.pdf], which seeks to produce "master hackers" much like "master painters"...
Take this with a grain of salt because I do not have a successful business or a rockstar CV, but I would argue that studying CS is of critical importance to writing good software. One does not need music theory to be a great musician but I think you will find that many great musicians with "no training" have some isomorphic model in their head with different terminology that they developed independently. Same applies to any engineering discipline.
Your application constitutes data flowing through various functions, processes, etc, and the algorithm you write to get those data from point A to point B and apply intermediate transformations can be represented, studied, and optimized mathematically. You may not be consciously doing it, but you are doing just that. Studying theory explicitly allows for unambiguous discussion and refinement of generalized concepts among different people, and an absolute framework on which to analyze and improve one's own understanding.
Or did I miss the point? I do find this debate engaging. And, yes, if you are studying to become a programmer or developer you may not need to dive into the proofs of why, but there should still be study of the what.
Here's the big problem. Incoming students usually pick majors as freshmen or sophomores. These students do not understand the difference between software engineering and computer science: they naturally assume that by signing up for a software engineering major they'd be preparing themselves for the exciting world of coding. After all that's what you're doing, right? Electrical engineering students learn to build actual circuits. Why shouldn't software engineering students learn to build actual programs? Totally reasonable.
Much of this problem is due to software engineering's misappropriation of the term "software engineering": but to students that term is largely synonymous with "software development" (and students aren't alone -- this is a common association in the industry as well). Unless software engineering faculty do a better job of explaining the difference, this will continue to be a major bugaboo.
The problem is that it's not in the interest of software engineering faculty to make this distinction to students, because to nearly all students, building a computer game is much cooler than defining its UML layout on paper. Departmental budgets are driven by butts in seats... why make it clear that a student who wants to code that he's in the wrong major because of an unfortunate terminological distinction coined in the late 1960s?
Before you get there, on their websites, and on arrival they should explain.
"This experience is all about the meta. Not learning <blub> but how you could design <blub> itself. By the time you are done whatever you haven't learned seeking to complete your education here will be exponentially easier to learn because of what you spent your time here learning.
How to learn. Better."
Well, one does come to mind. I've been told to get an Architect's stamp in Germany you need to have done a significant body of work in an area related to architecture, say bricklaying, or some other such trade. If this is true, I think this would show a similar sensibility as I hold, and the comment at the link mentions -- academic pursuit of algorithms is aimed at and motivated by totally different things than software engineers who need to push and release code NOW.
It would be nice to have them talk more, though. If I were king of CS programs worldwide, I think I'd implement a multi-year practicum requirement as the master's equivalent -- no serious academic work can be taken without going out and building some real world software in your area(s) of interest.
Then you can go play with algorithms and stuff, THEN you can go back out as a PhD/Certified Software Engineer and crush everyone you see..
In the second year the SE modules were mostly a practical team project, collaborating with another remote team from another University, designing and developing PDA and desktop geocaching software, for a client (representatives from IBM).
I strongly believe that for doing this course/project we were much better suited to industry, having developed soft skills that could otherwise go a miss from an academic course.
Alongside this we also has the theoretical CS modules, so it seemed like a good mix, and you could specialise however you liked in your final year.
What specifically in software engineering does it require an offshoot a new major? Languages, tools, how to work in a team? You can have just one class that is required for that instead of having an entirely separate major. All those things can become outdated quickly. You can also provide student-run courses or hackathons for generating real projects outside of class.
I might sound callous, but I'm honestly curious what kind of material would be taught in "Software Engineering" major that would separate it from computer science as a major?
http://www.dreamsongs.com/MFASoftware.html
If anybody ever made this happen I'd come running.
In all honesty, the actual coursework was pretty useless. I don't think that it's really possible to teach a lot of true SE concepts in a classroom. They're social paradigms that are constantly in flux, and very difficult to effectively teach.
The project itself was more helpful to me because of the group nature of the work, which meant that we had to work out scheduling, progress metrics, etc. Again, this is more of a social system than academic work.