I think what's changing from a business perspective is what kills software projects. What keeps a project manager up at night?
1980: Being too slow to run or not being able to an amount of memory we'd consider tiny is what kills projects. Large programs are relatively uncommon because the default languages (C and assembler) are so low-level that writing them is pretty much impossible. Programs exist to solve defined problems, not to be million-line ecosystems. In this world, being a decent programmer means you have to know about things like the performance trade-offs of pre-increment vs. post-increment.
2011: It's rare that a program, unless it's using O(n^2) sorting algorithms on large sets, is actually too slow to be useful. What kills software projects is illegible code. Paying a performance penalty for readability is generally a good idea, and highly-optimized but illegible code has fallen out of favor. This also means that fewer people are learning how to write such code, because people encounter less of it to read.
Technical debt is something that sinks projects, but it's by no means the only thing. This keeps engineers up at night, not project managers. A project manager worth his salt is worried about selling the wrong thing. Plenty of systems are messy, impossible to update, and wildly successful. I've worked on some of them. But few - if any - systems get away with solving a problem nobody has.
You hint that the goalposts have shifted for engineers, and that's a good point. Moore's Law gave us the room for a much stronger culture that worries about abstractions and meta-things like maintainability and cleanliness. But more importantly, technical restrictions have been lifted that previously prevented users from getting they software they need.
I agree with you, except for the dates. It seems to me that worrying about programmer productivity over performance is a phase that we're coming out of. Mobile devices, with less memory and slower CPUs & GPUs than the desktop PCs we're used to are the hardware platform du jour. Also, more people are having to worry about scalability which goes hand in hand with performance: it's not just about smart algorithm choices, kids...
Do you have any supporting references? Legible code is a minimum requirement.
It is like saying "code which dies every full moon is killing software projects." Sure, such code would kill most software projects -- but it is common today?
(My educated guess would be that slow development speed is the real mass murderer of projects.)
1980: Being too slow to run or not being able to an amount of memory we'd consider tiny is what kills projects. Large programs are relatively uncommon because the default languages (C and assembler) are so low-level that writing them is pretty much impossible. Programs exist to solve defined problems, not to be million-line ecosystems. In this world, being a decent programmer means you have to know about things like the performance trade-offs of pre-increment vs. post-increment.
2011: It's rare that a program, unless it's using O(n^2) sorting algorithms on large sets, is actually too slow to be useful. What kills software projects is illegible code. Paying a performance penalty for readability is generally a good idea, and highly-optimized but illegible code has fallen out of favor. This also means that fewer people are learning how to write such code, because people encounter less of it to read.