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.
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).
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.
I have degrees in CS and EE as well, and I was actually talking with one of our lab instructors on this topic yesterday.
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.
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].
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.
I always find it interesting how two people can have completely different experiences from the same school. I earned my CS degree at TAMU, and I only had one real SE class. It was aptly named "Software Engineering". Everything else was still theory, Algorithms, Formal Languages and Automata, AI, Programming Languages, etc. I graduated in 02, so not sure how things have changed since then. I did notice they changed the Dept name.
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.
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)
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 ;-)]).
Is there any major, including CS, which reliably imparts upon its students a proper understanding of the innards of a compiler? It probably depends on the school.
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 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.
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).
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.
> 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.
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.
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.
> 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.
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.
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.
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.
Sounds very similar to the Information Systems program, too. My girlfriend is pursuing a Business Administration heavy Information Systems program, whereas one of my roommates is about to graduate in a web-dev oriented Human-Computer Interactions and Information Systems double major. Yes, software engineering is a big and distinct field from Computer Science. But I'd say CMU gives plenty of options to make use of your CS or IS major.
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.
>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.
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".
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"...
> 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.
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.
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?
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.
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.
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..
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.
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?
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.
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.
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.
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.
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? :)
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.
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.