Hi Larry,

While I respect your experience in the field, I have to say I suspect that you're wrong. I'm a programmer also (albeit not at your or John's level, I'm sure), and it has long seemed to me that software engineering for space systems has gotten badly out-of-date. Particurlarly within NASA (less so within private industry and the DoD), It has seemed to exist in its own little isolated enclave, entirely unaware of the innovations of the rest of the industry. To wit:

- Realtime mission-critical software didn't even exist when the Apollo missions flew. So they had to invent everything themselves. This is no longer the case -- there are many off-the-shelf realtime embedded OSs which are absolutely up to the task of flying a lunar lander. These are the same systems that are responsible, for example, for the daily electronic shuffling of however-many trillions of dollars, so you can be certain that they are up to mission-critical tasks. And these sorts of embedded OSs can be purchased for a few thousand dollars -- not a few hundred million.

- Rad-hardened ICs and solid state memory simply aren't that exotic products. Have you noticed the way the shuttle astronauts use fairly standard IBM notebooks for all of their work? True, those aren't running the mission-critical functions, but it's slightly comical to think that those little machines are a couple of orders of magnitude more capabable than the STS computers, while costing a couple of orders of magnitude less.

- Unexepected event interruptions are something that all commercial realtime OSs have to deal with these days; they're simply not that big a deal. If you run your systems in parallel, then that can compensate for the temporary shutdown of any part of the computer. Note that this is exactly what the shuttle did with its 200-pound drums of ferrite-core memory -- so as long as you're going to be doing things in parallel anyways, why not use more conventional components?

- Running software on such limited and antiquated systems, forcing you to write all of your code in such a highly optimized fashion and in a very very very low-level language, drives up the development costs severly, while making the testing and debugging that much harder. If video games were programmed this way, then they'd cost $1000 per line too, or else be unplayably buggy. Using a high-level language increases your reliability, while decreasing your development costs. In the early days, of course, we didn't have this option. But now we do.

In short, I can see why space systems software once had to cost as much as it did: they were treading on wholly new ground, using computers that couldn't wrap their brains around my wristwatch. That made their job really, really tough, I'm sure. But things just aren't like that any more. Using a commercial realtime OS, running in parallel on a bank of Pentiums, and programmed with a relatively high-level language, I am quite certain that perfectly adequate lunar lander software and hardware could be put together for under a million dollars.

Cheers,

Nathan.