> What seems to be a better direction to go with 'sucky software' is the
>really basic stuff. What failures exist because of poor practices that
>repeatedly cause a loss of 5 minutes or fifty cents (shillings, fenig, etc.
>for our international readers). How much time is wasted by engineers
>hunting down errors because the compiler did not make a sensible check, or
>the engineer is allowed to goof. How much time do I waste when a web
>developer makes an error on the 4th of 6 pages of forms to fill out and I
>start over again 3 times before writing a nasty e-mail to tell them to get
>it fixed? I think these are much more applicable 'sucky software' problems,
>and in many ways more interesting to see why people hang on to silly taboos.
I would tend to agree with this. I have read the article now, and I feel it is
rather harsh on the software engineers who, as many people have pointed out,
were probably told by someone in management that there was no need to re-test
after the wiring had been changed on the legs for example.
I have experience of working in the European space industry during the period
just after the Ariane V disaster. There was obviously a lot of arrogance
involved in that incident (especially as far as the management is concerned) but
again the failure was blamed on the code.
Ultimately any software product can only ever be as good as the requirements ask
it to be. If the requirements do not state what is wanted clearly, succinctly
and unambiguously then there are always going to be failures of this sort.
There is a lot of crap software around, especially from the likes of Microsoft.
This is well known, but you generally don't hear of any catastrophic failures
caused by Microsoft programs. On the other hand, failures such as the Mars
probes get headline news because of:
1) The costs involved in the development
2) The hopes of those involved and interested in other planets (of which there
No one really expects Microsoft products to work properly so it's not a big deal
when they don't, but it should be.