Thursday 20 November 2003

Rocket Science

Rocket Man has a remarkable article on the testing involved in making a booster - in this case, the Atlas-V.
The amount of engineering that goes into designing, building and testing a rocket is staggering. Since the cost of failure is so high, almost every part on a rocket is subjected to at least some testing before it is flown. The very first time a new design is going to be flown on a rocket, it is put through extensive testing that tries to simulate the exact loading it will see during flight. But even after a part has been flight certified, subsequent parts are still tested to verify that they were built properly.
The whole article's worth reading - then consider that these are single-use devices, all they have to do is work once, and that's it. It's OK for it to wear out quickly. Making stuff that can be re-used repeatedly is much harder, and requires even more outrageous design effort.

Space Software is comparatively easy: it can be run on simulators and repeatedly tested without wear-and-tear. But it has to run on hardware that's subject to all the stresses imposed by Vacuum, Radiation, and massive Thermal differences, due to being exposed to an unshielded fusion reactor, then plunged into deepest shadow, sometimes once every 100 minutes or so. And it's got to work, regardless of any minor problems with the hardware.

Consider how reliable your PC is, the one you're reading this on. Now, especially if you're a Windows user, consider how horribly unreliable the software is. It's possible to write code that won't crash (or even hiccup) for days, weeks, months and years. So why doesn't everyone do it?

Now you know why I, and "we happy few" people involved in making programs to control air traffic, railways, weapons systems and the like are engaged in doing Don Quixote impressions when it comes to Software Quality for the commercial world. Some of us are Australian, others English, others Swedish, American, German, French, Ukrainian, Russian, Chinese... In many cases our techniques are not just better, they're cheaper and faster too. They have to be, or, given the insanely exacting requirements, nothing would ever get delivered.

No comments: