One day, software engineering will become a proper engineering discipline. I don't know when. Maybe it is, in the case of the software that they put on spaceships that has to be written and rewritten and tested and proven a load of times. I'd like to think so. All I know is that doing software well will always cost more than doing it badly. Therein lies the rub.
At a certain level, this is what a test-driven development is meant to accomplish. You write all the tests that show your software is working within specification, then you write the implementation to pass the tests. In practice? You've got the halting problem, which says that you can never be 100% sure that your process won't freeze unless you severely constrain how you program. You've got a workforce primarily composed of arrogant kids out of college who would rather make a name for themselves working on "sexy" projects than write documentation and audit code all day. And you've got the managers above who prioritize "it works" over an elegant solution.
Right, this is what I had in mind. There are definitely better ways to develop software than others, TDD is one. That's what the idea of SE means to me. Halting problem says that there doesn't exist a terminating decision procedure for all programs. You can still prove that a program terminates using Hoare logic or something similar.
No it won't. You need a stable body of knowledge to have an engineering discipline, and attempts to build one for software do more harm than good; see UML architectural astronautics and the patterns cargo cult. Engineers wouldn't have one either if they got to replace physics when they found it inconvenient.
I wish people would stop talking about software engineering and software architecture. We have a bad habit of believing analogies too much in software. It works well in AI, it doesn't work well in how we think about what we do. What we do isn't really like engineering at all. We could become an actual profession, with an enforceable code of ethics, but I doubt that will happen either. It has fewer advantages than it used to, and people would balk at not being able to form corporations for some sorts of software companies.
You make a good point regarding software engineering having no stable body of knowledge (apart from project management - The Mythical Man-Month?). I agree that analogies are shit, unfortunately the practice of using them to explain things is easy to pick up and hard to lose. Have you read "The cruelty of really teaching computer science" by Dijkstra? A lot of what you have said reminds me of that essay (regarding analogies). Program derivation sounds interesting, though. I'm tempted to say that that would count as "Software Engineering". Do you know anything about this?
Analogies aren't necessarily shit, you just need to keep in mind how deep (or shallow) they are. "Software engineering" is a very shallow analogy. You can use it to give laymen an idea what it is you do, but you don't want to believe it too much yourself. The predicate transformer stuff Dijkstra advocated was beautiful. Pick up a copy of David Gries's The Science of Programming if you can find it. Formal methods aren't worthwhile for programs that aren't really high risk though. Even in mathematics you only get that formal for important and hard theorems. Dijkstra was great, but he was still a product of his time, and Dijkstra's time was still a little too in love with formalism because of all the exciting stuff happening in mathematical logic in the first half of the century. By all means prove your space shuttle control system and pacemaker correct, but trivial CRUD forms are fine if they're legible and have some tests.
However, on September 23, 1999, communication with the spacecraft was lost as the spacecraft went into orbital insertion, due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf×s) instead of the metric units of newton-seconds (N×s) specified in the contract between NASA and Lockheed. The spacecraft encountered Mars on a trajectory that brought it too close to the planet, causing it to pass through the upper atmosphere and disintegrate.
That's the Soviet Union's official "Dr. Evil" space station, Polyus (or Skif-DM): http://en.wikipedia.org/wiki/Polyus_(spacecraft) It was put together in a crash program to counter Reagan's SDI initiative. It was a scary fucker - giant megawatt CO2 laser, "nuclear space mines", 23mm cannon, all sortsa good shit. The Soviets put it up in May '87 but because things were a little too fancy with the insertion, it had to go through some complicated maneuvers to actually get into orbit - detach from the Energia, rotate 180 degrees and fire boosters. Depending on who you ask, it either didn't respond to inertial sensors or somebody committed a sign error. Anyway, it detached from Energia, rotated 360 degrees and fired boosters, thereby slowing its velocity and de-orbiting into the Pacific. It wasn't declassified until the 2000s, at which point nobody could make headlines about failed Soviet doomsday satellites. "I'm not entirely sure the error was accidental, although I've found no discussion on the subject," he said conspiratorially from under his tinfoil hat, "as is often the case with successful interdictions."
I've got quite a few friends currently writing code that will be in orbit within a year or two, and most of them already have quite a bit up there already. Mostly CSTOL code. Software is constantly shit on, budget-wise. The mechanical and electrical engineers take a pretty nice chunk, which is warranted, but the low-balled budgets that NASA receives and awards to contractors seem to really hit the software engineers hard. That isn't all bad though; they're the most unregulated branch of the engineering triumvirate (mechanical, electrical, software), the least subjected to QA and paperwork. Of course, that won't last. You are absolutely correct in your assertion about quality... it's all about how much money you're willing to throw at it. Unmentioned case #1 Unmentioned case #2 There are many more examples, most of which are likely classified. Hardware is important too... don't mount your velocity sensors upside down