[crpatino]

> 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.