How did software get so reliable without proof? (1996)

4 points by typesanitizer


typesanitizer

Came across this PDF shared by Lorin Hochstein on Twitter, thought it was a fascinating time capsule. While I was reading this, I felt like many paragraphs could individually be expanded into a full-length article (if not a whole talk!), so I thought it was remarkable as to how Sir Tony Hoare manages to condense each topic down, and moves seamlessly across topics.

Writing skill aside, some bits that stood out to me:

Under section 2 Management:

The most profitable investment of extra effort is known to be at the very start of a project, beginning with an intensified study not only of the requirements of the ultimate customer, but also of the relationship between the product and the environment of its ultimate use [..] Above all, the strictest management is needed to prevent premature commitment to start programming as soon as possible. This can only lead to a volume of code of unknown and untestable utility, which will act forever after as a dead weight, blighting the subsequent progress of the project, if any

Under section 3 Testing:

But computing scientists and philosophers remain sceptical. E.W. Dijkstra has pointed out that program testing can reveal only the presence of bugs, never their absence [..] How then can testing contribute to reliability of programs, theories and products? Is the confidence it gives illu- sory?

The resolution of the paradox is well known in the theory of quality control. It is to ensure that a test made on a product is not a test of the product itself, but rather of the methods that have been used to produce it—the processes, the production lines, the machine tools, their parameter settings and operating disciplines. If a test fails, it is not enough to mend the faulty product. It is not enough just to throw it away, or even to reject the whole batch of products in which a defective one is found. The first principle is that the whole production line must be re-examined, inspected, adjusted or even closed until the root cause of the defect has been found and eliminated.

[..] Many more tests should be designed than there will ever be time to conduct; they should be generated as directly as possible from the specification, preferably automatically by computer program