This is the same argument as the long running feud between the 2 famous billiards players Willie Mosconi and Minnesota Fats. Willie was world champion and had won many tournaments. Fats never won any championships, but won a small fortune playing for money. When they played each other, Willie creamed Fats, to which Fats responded, "Big deal, how much money did he win?"
Computer science is Willie. Software engineering is Fats. It may not be elegant and precise, but it gets the job done and earns lunch.
That comparison makes no sense to me. Software engineering is to computer science as mechanical engineering is to physics. They're not in a competition.
there is also a very good movie (the hustler, paul newman + jackie gleason) concerning these two characters.
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...
The only problem with that comparison is that Willie does not help Fats to get his fortune at all. However, software engineering heavily depends on and benefits from computer science.
It's good to hear this argument once in a while - and I think it deserves to be extended to most things that are not formal figments of human thought.
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.
Wait...you're telling me techne and episteme aren't the same? And that it's hard to reconcile craft and science using the tools of science alone? Whatever will we do?
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.
I believe that the difference between Software Engineering and Computer Science is not in human activity (mind you, Computer Scientists are affected by that discipline: how about reading papers and such? Reading and understanding heavy math is never an easy thing).
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).
I do not agree with the thesis stated that "software engineering is slippery because humans are unpredictable". Maybe it is harder because it deals with humans, but good and solid research is possible, just look at areas like information retrieval.
The field of "human sciences" is slippery.
Economics, as a mere example, aims to be a "real science" and there is "good and solid research" but, nonetheless, the results are under our eyes.
I will not try to ask why this happens, many epistemologists have tried to.
umm, hehe, yah testing and high reliability, yah yah but umm - mathematics is a different kind of predictable...it's that kind of predictable where even if you don't know anything else, is it still true? yah. if we were in a different multiverse, where the laws of physics are varied in some ways, would it still work? yes. deduction is a beautiful thing.
This is a great article but only states the facts. The problem seems almost intractable, the Mythical Month asserts it in the No Magic Silver Bullet essay, in particular the following:
"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 fundamentally agree with the author, even though I'd frame it differently. I vastly prefer living as a Software Engineer than my days studying Computer Science, because it's not all sterile, formal, and rigorous, but is open to more complex analysis, more open-ended, and always with new things to learn. It appeals to a different mind-set, to be sure, and our traditional educational path has a serious mis-match for people who want to be Software Engineers, but I like dealing with the real world cases and the human element.
> vastly prefer living as a Software Engineer than my days studying Computer Science, because it's not all sterile, formal, and rigorous, but is open to more complex analysis, more open-ended, and always with new things to learn.
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.
Software engineering will never be a rigorous discipline with proven results, because it involves human activity.
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?
Designing and building cars is engineering, but it's not a science. It's not a "rigorous discipline with proven results" in the way that, say, physics is.
Just in case we didn't have enough metaphors, Software Engineering is to Computer Science as Cooking is to Baking.
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.