I love the name-dropping here. Perhaps you meant
Bjarne Stroustrup?
That's the one! Thanks for looking it up for me. I sorta felt like it was a bit wrong, but I figured you'd know who I was taking about.
One anecdote does not validate your point and it's a logical fallacy to presume it does. Were you more familiar with the "physics-y," "aero-spacey" stuff than this CS student? Did you meet the requirements of ensuring it was cross-platform? But congratulations on getting the project done on your iPhone before a CS grad.
Of course it doesn't prove my point, it's just fun. I included it mostly for rocketman to chuckle at. Here's another fun anecdote: One day Stroustrup came down to give a major seminar on C++0x in the CS lecture hall at TAMU. The CS department had refused to participate in the university's wi-fi network, using their own authentication methods instead. Since aerospace was on the floors above them, we were kinda stuck with it, but we had labs in other places so we'd all been through the hassle of getting both networks set up. Stroustrup spent more than 15 minutes at the beginning of his hour-long talk just trying to log in to the network so he could show some information from his personal web page, but he was ultimately unable to do so because the wi-fi reception from the CS network was so poor in the lecture hall all he could attempt a log-in was the regular network he got from the ethernet cable. I felt vindicated for all the times I had trouble logging in to the CS's complicated Wi-Fi network, (which had terrible user support, btw).
It's quite unfortunate, since I do agree with the core sentiment you're proposing. It's simply that your delivery comes across as smug superiority and is not all that beneficial.
People keep telling me that, and yet I keep delivering products early, under budget and expertly executed. The folks who work with me know that even when I seem smug and arrogant, I'm always ready to listen to any technical criticism of my work that someone has. I learned that in Physics because if your research contradicts the actual laws of physics, you can't hide it, and it was reinforced in aerospace, because when we make mistakes, people die horrible deaths; so we don't let our pride get in the way of rigorous engineering.
There are many factors that make "engineering" and software development different and cause it to lack the robustness you outline. I would argue one of the crucial ones is the barrier to entry -- it's significantly lower for software development. All you need is a computer (or even just an iPad).
This is achieved in many ways, not the least of which through the levels of abstraction computer science inherently drives toward. I don't think it has much to do with ethos. Framing it in those terms makes it an inherently offensive statement.
I had to look up "ethos", and, no, I disagree; it's precisely the ethos which makes it a problem. (Not that I disagree with your statement about low barriers to entry, that's what made getting a software job such a good option when I graduated and the aerospace industry was in a nose dive. But surely you won't argue that the barriers to entry don't affect ethos?) Rigorous engineering doesn't rely on delivering a 'bug fix' after the products are already out there. I know, I know, "Hubble" is like the giant anti-example there, but how many other aerospace missions get do-overs? 4 or 5. In traditional hardware engineering, bug fixes are ridiculously expensive. Not so in software, just upload new code. The consequences aren't thought to be as bad, so it doesn't get as much care as it should. I think the "we'll just send a bug fix" mentality is part of the software ethos, and I think development tools and development strategies should be less reliant on such solutions.
That's one reason why I use Mathematica instead of MatLab: because my equations in Mathematica look like the ones in my textbook and that the professor wrote on the board and that I publish in my papers. In MatLab, they look like DOS. Mathematica is easier to catch mistakes in my math. In fact, it's gotten to the point where I don't make mistakes entering equations, only mistakes in the ridiculous blocks of type-written code that get interpreted as control and data flow algorithms. Sure simulink is a great solution for visualizing data flow, until you have to do anything that's not actually in a textbook, at which point they're all custom blocks anyway.
But sure, the other guy brought up the science/engineering distinction, and I agree wholeheartedly that there's an important mindset difference between science and engineering. I ran smack into that in grad school. But the concepts weren't
new, there were just different emphases. In fact, exploring extreme regimes is a core way in which we learned to determine the reliability of our physics concepts. Maybe C++11's inherent atomics will fix the problem, but ... I'll just fix the rest of this sentence in a bug fix....
😉 Writing really thorough documentation (and including reliability analyses in it) wasn't a new concept in aerospace, I just personally had a particularly terrible lab prof in physics who happened to be responsible for teaching us how to write lab reports, and he did a terrible job. I learned my documentation skills from other prof's. Heck, Mythbusters actually has better documentation than some libraries out there... (Cue Kari: "Oh, we forgot the Newton's laws!")
Then again, in the sciences, there's always an inherent tendency to feel that one's scientific endeavour is somehow superior or conducive to the other.
XKCD has already attacked that issue. Mathematicians still win.
😛
I was even thinking of looking up that strip when that other guy mentioned the jokes other students tell about CS majors, but didn't have time. Thanks for finding it. I once thought about making fun of geology students, but realized they got more fields trips to go climb around rocks than I did. Then I added geology as my secondary. (Can you find that great xkcd about correlation and causation?)
----------
My sample size is 3 schools.
😛
