I think this is a bigger problem than is being recognized here. Most coders that I work with don't get to decide on ship dates. They may in a few cases have a claimed "veto power" if the code isn't ready, but they won't use it, because they'll be let go if they don't ship on time.
The management that I see is too often of the "Give me a demo. What are you talking about, that works fine! Ship it! Let's move the press date up by two months!" variety. Some of the better ones are of the "What's our risk exposure? Hmm... Versus the revenue model... Hmm... It's a close call, but I think the we have to go with the risk to hit our targets" variety. At least they *get* that there is risk.
But the fact is that management and investors don't care if software is buggy and insecure as long as those are "edge cases." They're fully onboard with the Fight Club model. "How many clients will get screwed vs. how much money will we make. Sounds like a good tradeoff."
I think most coders are capable of producing good code in a world in which good code is valued. The problem is that it isn't. Shipping products early and often are the values, and management tends to think that if we can ship code early, do write-offs for the bug and vulnerability cases, and then release the next version before having to patch the one that's about to be shipped, then the entire expense of refining and auditing code can just be eliminated.
At least that's been my experience—the idea is that it's a good way to reduce cost. Release a lot. Be "agile" (hate that word these days), which means: just keep releasing completely new code at an alarming pace. That way, you never have to create good code. You produce a pile of rapidly chucked out, 50% entirely new dogshit every three months with your programmers just barely managing to keep up, you release major versions as fast as you can. Consumers and clients don't get time to be exposed to major bugs and vulnerabilities, or to request that they be fixed, because you release fast enough that your answer can be "That product was released six months ago and is now EOL; no fixes are planned. We recommend that you upgrade to the new version." (The new version also happens to include another revenue item of some kind—upgrade fee, etc.—which is better for the bottom line than providing bug fixes for free.)
I think what we see in software is the same thing we see across the rest of the consumer landscape. Managers and investors have realized that disposable, non-repairable junk is better for the bottom line and for themselves, because it means that consumers have to keep paying over and over again, and often. All of the other employees (e.g. coders) are left to come along for the ride by the seat of their pants, or get fired and replaced by someone who will.