Elliotte Rusty Harold wrote:
> At 7:03 AM -0800 12/31/04, Benjamin Franz wrote:
>
>> People treat software like it isn't real. Software machines are just
>> as real as hardware machines - and often control hardware machines.
>> If you are killed by a radiation therapy machine because of broken
>> software - you are just as dead as if the cause was broken hardware.
>
>
> Yes, but there is a qualitative difference between software failures
> and hardware failures (though the effects of either can be equally
> damaging). Software mostly fails due to outright bugs and failure to
> anticipate certain conditions it encounters. However, if it works in a
> certain condition, it always works. Hardware can fail for these
> reasons, but it also has an additional way to fail most software
> doesn't: it decays over time as parts wear. It is completely plausible
> for a piece of hardware to work 10,000 times in a row and then fail
> the 10,001st time, even though nothing has changed. This style of
> failure is very rare for software. Software needs to be upgraded and
> maintained to handle changes in the environment where the software
> runs, not because the software wears out.
i basically agree (i use the argument to beat up users all the time -
they changed the procedure, not me changing the software that caused the
failure ;) ). however my experience to date is that 1) software failure
cost can be analysed the same way as hardware failure cost - probability
* expected cost = expected loss (and we use this to prioritise
maintenance work); 2) software systems do degrade, as mentioned by
changing external systems. but with modern hardware reliability i think
hardware now has more in common that software in this respect. eg most
of the hardware upgrades we complete are now due to obsolesence rather
than failure - or if you prefer performance below expectation is a
failure mode that increases with time 3) in spite of 40+ years of
research there is still much to do in the understanding of software
failure modes. the discussion on exception handling demonstrates just
how complex failure detection/management can be and 4) the isolation of
software from the hardware it runs on, seems to me to be a conceptual
error. to some extent the reliability of software is a function of the
reliability of the particular hardware involved (much as we'd like to
ignore it). some of the dicsussions on memeory / disk limits point to
the subtleties of this - what sort of failure is it when you can't
process an xml document in memory because you ran out of memory?
hardware or software?
rick
