There seems to be a disconnect between his argument for tighter engineering standards as the single key for building better software and the stated fact that software is not bound by the constraints of physical reality.<p>In designing and producing the physical components of a 747 (like a bolt to use his example), there isn't the same level of potential abstraction as there is for even a very basic software component.<p>The fact that he's talking specifically about the development of a secure OS does strengthen his argument though. So in that sense I agree with him.
We insist that software should, for any input, either accept and work normally (if the input is valid) or reject and fail gracefully and safely (if the input is invalid). I'm not yet convinced that applying this standard to engineering projects will find a much better success rate than applying it to software has found.