
Should top CS schools offer Software Engineering as a separate major? - ssclafani
http://nerdcollider.com/challenges/3/responses/64
======
kwantam
Having done degrees in both electrical engineering and computer science, it
seems to me that EE schools on the whole manage the theory vs. practice a bit
better than CS schools do.

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.

~~~
_delirium
I like the idea of diversifying, but CS borders a _lot_ of disciplines, some
of which it's either gradually annexing or gradually being annexed by
(sometimes it's not clear which is which ;-)). I'm not sure it's possible to
fit everything into 4 years, at least as all mandatory components, unless
someone decides by fiat where the boundaries of CS are.

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).

~~~
kwantam
It's fair to observe that there is a whole lot to learn. I'm not sure the
extent to which you're disagreeing with me, but I'll submit that if it's not
possible to learn it all in 4 years, adding a SE major won't magically make it
possible.

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.

------
gatlin
I have attended both UT Austin and Texas A&M, who both proudly and decidedly
adhere to opposing views.

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].

~~~
elbenshira
I'm studying at UT Austin, and I love all the theory work. It's challenging
and makes my brain hurts, but the insights you get out of all this work
changes the way you see programming and software engineering. You start
yearning for beauty and elegancy, much like the algorithms we study. You find
that you start thinking like a theorist in your every-day coding: what am I
trying to solve? What are the constraints? How do all the pieces work
together? Do I need this piece over here?

Some theory may not be practical, but learning to think the way theorists
think is very, very practical. And a lot of fun.

~~~
gatlin
Agreed. Hence my transfer ;) But I do respect what TAMU is attempting.

------
joegaudet
In all honesty (said as a Canadian with a Computer Engineering degree -- I
should note we take the term engineering a bit more serious here in Canada, we
don't allow people with CS degrees for instance to call them selves engineers)
I don't see why there has to be software engineering as a separate program and
not just a specialization of CMPE.

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.

~~~
grav1tas
I also think it sort of waters down Computer Science to wedge it into
engineering and treat it as such. Ultimately it's more about theory,
formalisms, and mathematical/logical foundations than it is about "making it
go". I think when we start treating a CS program like it's a EE/ECE program,
then the CS program is impeded by getting too caught up in the nitty gritty.
Don't get me wrong, I think the hardware portions are very important, but I
like writing compilers. I'll learn as much about a system as I need to get a
good compiler going, but the physical nature of a system generally are of no
interest to me. They should be somebody else's job (who enjoys such things and
derives pleasure in doing them [more power to them for it ;-)]).

~~~
scott_s
I've replied to similar sentiments on HN a few times:

<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.

------
endlessvoid94
I am continually astounded by the things my CS degree prepared me for. The
breadth that my CS program gave me (UIUC) is very good: rigorous theory
classes, introductory classes to systems, security, compilers and languages,
numerical analysis, RDBMS systems, information retrieval, the list could go on
forever.

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.

~~~
indraneel24
I might be enrolling at UIUC as an undergrad this fall. Could you spare a
minute and tell me a little bit about the CS dept. and the school as a whole?
Email's in my profile, if this isn't the right place to ask (sorry if I
violated HNettiqute).

------
jallmann
Absolutely, CS and SE are distinct fields of study. My school offered majors
for both.

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.

~~~
baddox
> _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._

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.

------
alavrik
Please don't do that! Programming is just not there yet.

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.

~~~
jallmann
Agreed 100%. Algorithms and data structures provide a better guarantee of
correctness than any design pattern ever will.

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.

~~~
Silhouette
> 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.

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.

------
jwuphysics
Carnegie Mellon University offers a Software Engineering minor as part of
their Bachelors in CS undergraduate program. As for the Master's degree, they
already have one.

I think students have enough freedom to mold their own strengths and passions
into the CS program here.

~~~
jbl
When I was there, there was also the Information and Decision Sciences
program. It was a little CS, a little economics, a dash of social science, and
a pinch of management.

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.

~~~
adestefan
My alma mater has the same type of program [1]. It's a mix of CS, business,
communications and finance. It's also a liberal arts school so you end up
taking another ~60 credits outside of your major. You take the classes plus 3
semesters of the capstone project. For the projects, you start as a "grunt"
and work your way into complete control of a project.

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.

[1] <http://www.juniata.edu/departments/itcs/i4i.html>

------
bane
Yes, most people who take CS probably mean to take something more like
Software Engineering (SWE) (actually they probably mean to take something like
Programming, but that's not generally a field of study, maybe I.T. or I.S. is
closish to what most people want to take, but the prestige just isn't there)

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.

~~~
cube13
>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.

~~~
bane
I have a feeling that in 10-20 years, SE will split into several independent
disciplines. There's quite a bit different in building say, an e-commerce
system from hacking code on a robotics kit.

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".

------
vilhelm_s
I definitely think this is worth trying. I love computer science, but I think
it is a fact that much (most?) of computer science is not very useful for most
programmers.

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"...

~~~
gatlin
> I definitely think this is worth trying. I love computer science, but I
> think it is a fact that much (most?) of computer science is not very useful
> for most programmers.

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.

------
nuclearsandwich
It seems really difficult to offer a compelling software engineering program.
Computer Science has a lot of history and theory that is well suited to
classrooms and professors. A software engineering program would have to be
constantly (at least each semester) evolving to explore all paths for
designing good software. In fact, we offer a Software Engineering degree at
San Jose State University, in Silicon Valley, we should have an unfair
advantage in that field. As a CS/Math major I am required to take a few SE
courses. All of them have been 10-15 years dated in both execution and their
definition of good software and what constitutes solid design. I'm so sick of
these SE classes that I'm tempted to drop out or transfer. Engineering (not
just software) is mastery of a craft, it isn't something you can learn by
passing classes and getting a degree. You need to get your hands dirty,
something other engineering disciplines focus on highly. For an SE program to
be effective there should be one class: Software Engineering 1, the curriculum
should consist of working with your peers to build awesome software. You
should have to take it at least six times. The instructor can mentor the
veterans and the veterans can mentor the freshmen The masterclass is to start
a project that you spin up into a publicly available piece of software, then
watch how you're design scales and what needs to change. Anything else is
history and lies.

------
foomeister
Interesting: he doesn't identify the biggest problem with offering Software
Engineering as a separate major. I have my suspicions as to why.

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?

------
wh-uws
I think the biggest problem with many CS schools is a more a marketing /
message one than anything else.

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."

------
codybrown
This is actually an ongoing discussion. Weigh in and vote here:
<http://nerdcollider.com/challenges/3/>

~~~
russell
Good call. One of commenters is Tony Wasserman at CMU who is one of the
fathers of Software Engineering who tells why he worked to separate SW from
CS.

------
vessenes
I had a bunch of thoughts about architects vs home builders, and nurses /
doctors, but when I thought about it, I realized that I can't think of any
directly analogous splits to the CS / Engineering ideas here in other
disciplines.

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..

------
adam-_-
I did a course that was mostly CS with some SE (SWE) modules. In the first
year the SE modules were about team work, version control, development
methologies, requirements analysis and so forth.

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.

------
HaloZero
Isn't this what internships and part-time jobs are for? Plus you can integrate
basic software engineering by working in teams in school or just have one
class.

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?

------
grav1tas
Is good software engineering something you can truly learn in the classroom,
or is it something that's emergent to applying good learning techniques to
real life experiences (kind of like being a journeyman)? I think a good
Software Engineering degree would be one that somebody who has a good amount
of real life programming experience would return to get to signify a level of
"mastery" in the field. My two cents at least. I don't want to act like I know
a ton about the trades, but I'd like to think that there is some similarity in
mastery of Software Engineering to being a master craftsman in both
learnedness and years of practice.

------
ams6110
In some state schools it might not even be possible. I remember discussing
this with one of my profs who told me that he was prohibited by state law from
using the word "engineering" in a course title or description, as the charter
for engineering curricula was with a different state university. The research
school had the CS department, the engineering school had the SE program.

------
nradov
Yes of course schools should offer students a choice, with CS focused on
theory and SE focused on practice. In addition to those I like Richard
Gabriel's proposal for a "Master of Fine Arts in Software".
<http://www.dreamsongs.com/MFASoftware.html> We need all kinds.

------
chromic
No. While there's lot of value of offering more courses that teach the key
aspects of software engineering, I can't see it ever being better than the
experience at an internship at a real company, which an any serious industry-
bound CS student at a top school should be able to find.

------
jfm3
I still like Gabriel's idea of an MFA in programming.

<http://www.dreamsongs.com/MFASoftware.html>

If anybody ever made this happen I'd come running.

------
gte910h
I think some of both is good for both sides of the coin: Why not just split
them into separate specializations?

------
barista
UIUC already offers a bunch of graduate level courses in SE as part of the CSE
program. If you take the courses, does it matter that the major is something
else? :)

~~~
cube13
Those courses were basically a senior design project with some added software
engineering topics put on top(the year I took it was extreme programming and
something else I don't remember).

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.

