Software Engineering ≠ Computer Science
ddj.com
ddj.com
In other words - can someone please forward this to the humanities department? Tell them it's OK to stop formalizing literature, politics, ethics, and the other messy fields of human endeavour. It turns out that things change regularly and generally applicable advice is much more helpful than obscure formalism founded on obsolete assumptions.
(Also: To those who say the above goes double for the economists: take it easy on the economists. They do get real results, it does work (mostly) - but realize their job is much more difficult than, say, that of physicists. Physicists have merely to understand and model the crazy phenomena that make up our world. They are lucky in that these phenomena tend to co-operate by not changing very often. For the economists, things are not so easy - so take pity on them.)
a farmer has a bunch of chickens that aren't laying eggs, so he asks a physicist for help.
the physicist leaves, does some calculations, etc etc, and comes back with the following answer.
"well I've solved your problem, but it only works for spherical eggs in a void"
I'm sure that economists have much the same issue. All of their theories work just fine with rational humans in a vacuum.As a fun aside, Connell's misunderstanding of the Church-Turing thesis is cute (though perhaps a little insulting to all of those computer architecture researchers in CS departments!). "All computing hardware is equivalent". I see -- I didn't realize that my 8bit 2-register CPU with 4KB of memory can do anything my 64bit 32-register CPU with 4GB of memory can do. But of course it can, because the lambda calculus can express any effectively computable function. Right, I see that now.
The differences are in scope and expectation of audience.
Usually, a paper of Computer Science deals with a limited and well-defined problem, while even the simplest program from Software Engineering must work on an infinite set of requirements, from security to ease of use. Plus, many of a program's requirements are in perpetual war with each other. Therefore, Software Engineering is slippery: sometimes, such and such requirements dominant, some other times, those other requirements are important.
Secondly, Computer Scientists demand a certain level of intelligence, effort, and knowledge from their audience (aka readers of their papers). Software Engineers have no such luxury: Just look at how they are screamed at just because a button is put at the wrong position. Plus, many computer users have come to expect that they are stupid and have absolute right to remain as stupid and ignorant as possible. Remember, computer programs are complex. Hiding away the complexity of the program, having an attractive interface, while still being correct, secure, and efficient must be satisfied at the exact same time. That's extremely difficult (if not impossible).
"there is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
My own experience over the last few years is that tools and method have improved but complexity and user expectation has risen to meet or exceed that this aligns with Brooks' thinking.
I would slightly beg to differ. Computer Science as a science is filled with interesting problems, is open ended, and will never be short on things to learn. It is however different in kind than the problems and things to learn that Software Engineering focuses on. It is more akin to mathematics (some would say perhaps correctly that pure computer science in this sense is a form of mathematics).
>our traditional educational path has a serious mis-match for people who want to be Software Engineers
This I agree with. Computer science as taught in most universities is a strange mismatch of hard theory and practical skills in coding, but very little in terms of some things that a practical software engineer must have such as gathering requirements and working on teams of programmers.
I think it might be wise to split software engineering into a separate (but closely related) degree.
That is utter nonsense, and that's easy to prove: A car's appeal often has little to do with its capabilities and everything to do with its brand associations. No-one drives a Maserati for its reliability or its ample luggage space! There are few consumer products where the "human factor" is more important than in the auto industry. Yet is designing and building cars not engineering?
They are very different fields...and going through school there was very little to be learned about the art of Software Engineering. Most people, I suspect, have to learn it on the job.
Computer science is Willie. Software engineering is Fats. It may not be elegant and precise, but it gets the job done and earns lunch.
however, the movie connections aside -- i am not buying this "sw-engineering" equals "it's a paycheck"-mentality. IMHO, the two disciplines are not easily comparable, this mostly stems from the fact that CS deals with "computing in the small", while SWE deals with "computing in the large" (actually, more "programming" than "computing"). i think this is also a major reason that research areas in both disciplines are not overlapping (aside from code generation which obviously uses theory from compilers, i am mostly thinking in terms of product-lines and variability-handling; please post if you have other areas in mind that i fail to remember ad hoc)
also please note: the mutual disregard for CS towards SWE and vice versa is actually counterproductive and i am sure that some interdisciplinary efforts could be mutually beneficial...