Thank you for demonstrating the exact problem with the state of software development today.
"If the Bold doesn't work, no one will die." How do you know that? I can think up scenarios where if the bold doesn't work, someone could well die. Patient care instructions where something other than the usual is normally highlighted in bold -- printout doesn't have any bold text, overworked nurse misses the special instructions, patient dies. (Sure, there are other problems in the overall methods and procedures if that happens, but it could happen.)
That sort of sloppy thinking gets carried through to other applications. Read the RISKS newsgroup (comp.risks) or digest for numerous examples. Not all fatal by any means, but ranging from that through having ones life ruined (think identity theft) and a few examples of plain inconvenience.
I guess my point is that, unless you know absolutely all the possible uses your software will be put, you'd better write it as though somebody's life depended on it, because it might. (Well, modulo the cost of such development, which is a real engineering trade-off too.)
We are in agreement there...
"If the Bold doesn't work, no one will die." How do you know that? I can think up scenarios where if the bold doesn't work, someone could well die. Patient care instructions where something other than the usual is normally highlighted in bold -- printout doesn't have any bold text, overworked nurse misses the special instructions, patient dies. (Sure, there are other problems in the overall methods and procedures if that happens, but it could happen.)
Well, what you are describing is not a Word Processor, which was what I was referring to... However, what you ARE describing would be something that, if used in the treatment and diagnosis of a patient, would be required to be classified as a medical device - in which case, it would require a 510K... In order to GET the OK to release, it would need to undergo far more stringent testing and validation - not so with Microsoft, for example, releasing Microsoft Word... Nice try though...
That sort of sloppy thinking gets carried through to other applications. Read the RISKS newsgroup (comp.risks) or digest for numerous examples. Not all fatal by any means, but ranging from that through having ones life ruined (think identity theft) and a few examples of plain inconvenience.
Preaching to the choir, man... I could tell you horror stories about bad software - software that kills - think 'X-Ray Machine of Death' as a perfect example...
I guess my point is that, unless you know absolutely all the possible uses your software will be put, you'd better write it as though somebody's life depended on it, because it might. (Well, modulo the cost of such development, which is a real engineering trade-off too.)
Well, since I work in a field where 'someone's life depends on it', I look at software different than a large percentage of the industry. Any software I work on is not a game, and I certainly do not look at it as such
The fundamental problem with software design verification is that marginal reductions in the number of defects have an essentially exponential cost. The market has declared that it is unwilling to pay ten times as much for software as they do in exchange for not having to patch as many bugs. There are companies and applications that actually do a proper rigorous design verification, going as far as doing module level proofs of correctness, but this is extremely complicated and costs a fortune. The only people that can afford software applications that reliable is the military and similar. A defect in a single line of code can cause a million line application to subtly fail in ways that are nearly impossible to detect. Proving the correctness of an application that large is an exercise in the intractable.
So it boils down to economics. Virtually no one can afford to eliminate all defects in non-trivial software applications, certainly not for the consumer market. It is the nature of the beast. Comparing it to conventional engineering is apples and oranges.