Personal observations on the reliability of the Shuttle – R.P. Feynman
ranum.com
ranum.com
Am in business with someone many years older than me. It has always struck me how little tolerance he has for risks to my safety. The natural reaction is to have more lenience for situations that wont directly impact your personal safety. Wheras this guy will do potentially dangerous tasks that would otherwise be my responsibility. His kids are grown up, mine are young.
It is the kind of attitude that would be near impossible to enshrine in a larger organisation (like NASA) but refreshing to see all the same.
> For example, cracks have been found in the turbine blades of the high pressure oxygen turbopump. Are they caused by flaws in the material, the effect of the oxygen atmosphere on the properties of the material, the thermal stresses of startup or shutdown, the vibration and stresses of steady running, or mainly at some resonance at certain speeds, etc.? How long can we run from crack initiation to crack failure, and how does this depend on power level? Using the completed engine as a test bed to resolve such questions is extremely expensive. One does not wish to lose an entire engine in order to find out where and how failure occurs. Yet, an accurate knowledge of this information is essential to acquire a confidence in the engine reliability in use. Without detailed understanding, confidence can not be attained.
I'm not sure that would be my takeaway from that quote. In the analogy of Unit testing, the test would have found the cracks in the turbine blades. It seems to me that Feynman continuously argues for deep investigation into any problems encountered, rather than (seemingly) ignoring them or making up excuses for why they're not problems.
He regards independent code verifications and testing highly, it seems:
> The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future.
I'd consider this quote a clear argument for unit testing though:
> There is additional verification in using the new programs in simulators, etc.
In the end, it seems to come down to the simple concept of: spending more time on verifying code results in better code. Whether it is through automated testing, code reviews, independent (and competent) user acceptance testing, etc.