Software Engineering ≠ 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.<p>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.<p>(Also: To those who say the above goes double for the economists: take it easy on the economists. They do get real results, it <i>does</i> 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.)

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 <i>do</i>?<p>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 <i>anything</i> 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).<p>The differences are in scope and expectation of audience.<p>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.<p>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.

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

<i>Software engineering will never be a rigorous discipline with proven results, because it involves human activity.</i><p>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?

Just in case we didn't have enough metaphors, Software Engineering is to Computer Science as Cooking is to Baking.<p>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.

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?"<p>Computer science is Willie. Software engineering is Fats. It may not be elegant and precise, but it gets the job done and earns lunch.

This reminds me of C.P.Snow's infamous "The Two Cultures" essay:<p><a href="http://en.wikipedia.org/wiki/The_Two_Cultures" rel="nofollow">http://en.wikipedia.org/wiki/The_Two_Cultures</a>