Slashdot Mirror
Computer Science vs. Software Engineering
theodp writes "Microsoft's promotion of Julie Larson-Green to lead all Windows software and hardware engineering in the wake of Steven Sinofsky's resignation is reopening the question of what is the difference between Computer Science and Software Engineering. According to their bios on Microsoft's website, Sinofsky has a master's degree in computer science from the University of Massachusetts Amherst and an undergraduate degree with honors from Cornell University, while Larson-Green has a master's degree in software engineering from Seattle University and a bachelor's degree in business administration from Western Washington University. A comparison of the curricula at Sinofsky's and Larson-Green's alma maters shows there's a huge difference between UMass's MSCS program and Seattle U's MSE program. So, is one program inherently more compatible with Microsoft's new teamwork mantra?"
In my opinion CS majors have always been the philosopher kind who like to nit-pick every angle of development. Product development leadership requires someone more practical as an engineer.
as if the schools these guys went to makes a difference? their skills are learned from experience working in the industry and their value is in using their judgement based on that experience to make the best choices.
Computer science is a branch of mathematics; software engineering is a collection of methods for applying that math in the "real world." Software engineering is not about state machines, compilers, programming languages, parallel algorithms, etc.; it is about how to use write "concrete" implementations of such things in a way that makes sense for real-world computation.
Palm trees and 8
It feels like we just discussed this a week ago - oh, wait, we did!
http://ask.slashdot.org/story/12/11/10/2038211/ask-slashdot-developer-or-software-engineer-can-it-influence-your-work
Another gem from timothy, right-supreme glorious editor for life.
An engineer uses his tools and techniques to solve problems.
A scientist invents new tools and techniques.
If you're just using your knowledge to build things for people, you're an engineer. Unless you're exploring the limits of knowledge, coming up with and testing new ideas, you're not a scientist. And publishing has nothing to do with it, it's a mindset.
Knuth is a scientist - by laying out algorithms and describing their merits and deficiencies, he's essentially publishing a box of tools that others can use. Bill Gates is an engineer - he implemented known algorithms and solutions into a unified package (nothing new there).
Same as any other science degree.
Most grads in math, physics, chemistry also end up doing relatively "mundane" jobs. A degree in bio-chem and you can be a lab technician. A degree in geology and you analyze oil drill results. Physics degree -- you might end up working on radio antennae...
Those guys are 50 something. The difference between Computer Science and Software Engineering does not matter 30 years after you graduated. Whether you kept up with progress and what kind of experiences you acquired during that time is what matters. Old guy did not left because of the school he was in and the new guy was not hired because of the school he was. They left / have been hired because of what they did last 7 years.
Software Engineering, in the sense of the Seattle University program, is the attempt to reduce the production of software to a set of reproducible steps that any monkey (code monkey) could accomplish. You know, you start with your requirements, you proceed to a high-level design using object oriented design techniques, then you make a low level design, and finally, almost as an afterthought, you write code. As anyone who has been on a software project which attempts to follow this particular discipline knows, it doesn't work. It does, however, succeed in its secondary goal of turning an interesting job into a horrible grind.
I suspect working on Windows is already a horrible grind, so it probably won't make much difference.
While not a perfect match to the above, I think the story of the king's toaster is a good example of the difference between an "engineer" and a "scientist". I originally saw this on USENET in the 1990s, so the technology is a little dated:
CS theory is not "nonsense" by any stretch of the imagination, even if you are only interested in doing "real world" work. The point of theory for professional programmers is to think about software in unusual ways; this broadens your ability to solve problems. The trend in programming languages over the past few decades has been towards the use of concepts that are common in theoretical CS; if that trend continues (and I suspect it will), theoretical courses will be more relevant as time goes on.
Even C++ now has lambda expressions. Introspection was once a theoretical topic (e.g. Turing machines that can read their own description). Type theoretic concepts (type constructors, dependent types, etc.) are probably going to become more mainstream in the near future.
Palm trees and 8
Computer Scientists create things like linux.
Software Engineers create things like Windows 8.
Not trolling, This is a complete fact. Far more high level CS degrees are working on linux and OSS than Windows 8.
Do not look at laser with remaining good eye.
I see you don't get the point of college education. It is supposed to stretch your mental capabilities so that when confronted with a new situation, you aren't without the mental faculties to understand and master it. Why should CS majors learn calculus? Because mathematical reasoning is important, and many CS people rub shoulders with engineers. You want to talk to them and be useful, learn your calculus...well.
Higher Education is just that Higher Education. It is not Trade School Skill Boot Camp so you can regurgitate the latest buzzwords MS and the rest of their ilk cram down managers throats.
Side note: I'm mystified at how someone with a Bachelor's degree in business can earn an MS in Software Engineering. Yes, management skills have an important role in an SE curriculum, but not to the exclusion of the technical skills.
Over paid for your education is doing it right.
signature is pants
THE TOASTER
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."
"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
My personal experience would be that computer engineer is a better place to start a career and then start sprinkling computer science more and more. The CS majors (the worst being the graduate ones) blah blah all the time about big O yet somehow never master the career basics such as SQL or Linux administration. I find that they get bogged down with Big O and other analysis on problems where O^8 will still take nearly zero time and O just doesn't matter.
Yet on the other end I find that many computer software engineers tend to master something like Java and then just wail away at every problem with their one mastered skill set. Then after a while they get a second skill set such as SQL and as time goes by they end up with a sort of vertical integration of skills. But where they don't usually progress is when you do have to look at a problem as a system and start doing discrete math, working out the nodes, connections, and so on. This is where computer software engineers will implement a cryptographic library but do it really badly leaving elephant sized holes.
So I would say CS is often too pedantic, CE is too much like a plumber, but a CE with strong math and a good dose of CS can generate art. Sort of like Escher; he could draw quite well and had a good understanding of math, he combined the two into something incredible.