How Did Software Get So Reliable Without Proof? (1996) [pdf]
1–10 of 126 posts
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#2This didn't age very well. Especially the part celebrating "over-engineering" including the explicit duplication of code, instead of re-use, since that is "risky".
I do however like the strong emphasis on (manual) testing.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#3tl;dr: The testing of code is done by intelligent adversaries.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#4One thing I would think helps software is Linus's law: "Given enough eyeballs, all bugs are shallow".
https://en.wikipedia.org/wiki/Linus%27s_law
As far as I know, this is not something available to other forms of engineering.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#5One thing I would think helps software is Linus's law: "Given enough eyeballs, all bugs are shallow". https://en.wikipedia.org/wiki/Linus%27s_law As far as I know, this is not something available to other forms of engineering.
Definitely true for my domain, mechanical engineering. Enough reviews and bugs will be found and corrected.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#6The first sentence of the article begins "Twenty years ago", and yet the article itself is undated.
This appears to be entirely normal for scientific papers.
Can anyone tell me how this foolishness came to be considered acceptable among scientists, and why it persists?
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#7The first sentence of the article begins "Twenty years ago", and yet the article itself is undated. This appears to be entirely normal for scientific papers. Can anyone tell me how this foolishness came to be considered acceptable among scientists, and why it persists?
Because traditionally, articles were published in journals, and journals had the date written on the cover, so it was superfluous to add it on every page.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#8One thing I would think helps software is Linus's law: "Given enough eyeballs, all bugs are shallow". https://en.wikipedia.org/wiki/Linus%27s_law As far as I know, this is not something available to other forms of engineering.
I don't think that's true, or at the very least it's misleading. Qualified eyeballs are often expensive, and moreover there are consistent intellectual biases of human beings that interfere with catching all bugs.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#9The first sentence of the article begins "Twenty years ago", and yet the article itself is undated. This appears to be entirely normal for scientific papers. Can anyone tell me how this foolishness came to be considered acceptable among scientists, and why it persists?
It depends on how you come across the paper. Peer-reviewed scientific journals (as well as some preprint channels that aren't peer reviewed) are fully explicit about the date of publication. However, if those same papers are published on another website, they might lack metadata such as date and publication venue. This is a good reason to link to the actual publication source instead of to a PDF copy of the paper (unless you have good reason not to, such as a paywall).
PS: in this case: it turns out that the paper was published in the International Symposium of Formal Methods Europe, 1996: https://link.springer.com/chapter/10.1007/3-540-60973-3_77
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#10This didn't age very well. Especially the part celebrating "over-engineering" including the explicit duplication of code, instead of re-use, since that is "risky". I do however like the strong emphasis on (manual) testing.
That section actually criticizes duplication, it does not endorse it:
> So it seems safer to take an entirely fresh copy of the existing code, and modify that instead. Over a period of years there arise a whole family of such near-clones, extending over several generations. Each of them is a quick and efficient solution to an immediate problem; but over time they create additional problems of maintenance of the large volumes of code. For example, if a change is made in one version of the clone, it is quite difficult even to decide whether it should be propagated to the other versions, so it usually isn't. The expense arises when the same error or deficiency has to be detected and corrected again in the other versions.
Note his use of the phrase "it seems safer", he doesn't say it is safer and at the end explains what the actual risk/expense is with the copy/paste approach.
And at the end he discusses the issues with over-engineering in summary:
> The limitation of over-engineering as a safety technique is that the extra weight and volume may begin to contribute to the very problem that it was intended to solve. No-one knows how much of the volume of code of a large system is due to over-engineering, or how much this costs in terms of reliability. In general safety engineering, it is not unknown for catastrophes to be caused by the very measures that are introduced to avoid them.