I couldn't disagree with you more. This paper offers no insight, only excuses to accept that software will always be buggy. If anything I'd encourage young engineers to explore technologies that have been not been explored to their fullest potential. Computer Science is a very young field and many unexplored paths such as flow based or some automated programming method that hasn't been dreamed up yet that may lead to far more reliable software.
I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. We should just accept buggy CPUs because of the complexity in designing CPUS with 7 billion transistors.
> This paper offers no insight, only excuses to accept that software will always be buggy.
The paper does not address the problem of buggy software, though it is related. It addresses the problem that software is complex.
And the insight it offers is that not all complexity is equal: there is accidental complexity (programming is hard because the way we have done things historically is not yet optimized) and inherent complexity (programming is hard because we are modeling complex stuff and it is inherently hard for human minds to juggle all the relevant details).
The excuses you complain about are really examples where people confuse one with the other. i.e. you cannot solve the problem of Requirement Gathering with better compilers because the problem is not technical, it is that stake holders are playing political games in the background, so if left to their own devices they'll give you vague, confusing requirements now with the tacit intention of leveraging those when the inevitable struggles come in the future.
> I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s.
I am sorry to inform you that an EE version of this will be direly needed in the near future. As the Moore law keeps hitting more and more fundamental limits of physics, we need engineers who are able to work in the problems that matter and make hardware that gives us the best possible performance given the constrains available. It would not do to have each generation of young EEs to start yet another cargo cult every 5 years or so, wasting valuable resources in the attempt to pack twice as much transistors per wafer.
> This paper offers no insight, only excuses to accept that software will always be buggy.
Is that how you read it? I read it as a call to accept an open eyed view of the industry and its advances, and tirelessly work to make progress rather than believe in messianic fads and jump from one to the next. It is optimistic yet realistic, and warns against unconstructive zeal.
I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. We should just accept buggy CPUs because of the complexity in designing CPUS with 7 billion transistors.