A Plea for Simplicity – You can't secure what you don't understand. (1999)
schneier.com
schneier.com
Most of the material in my Software Engineering course is outdated, but I imagine most companies still try to get away with minimum security and slack on good software engineering practices, like code reviews and static analysis and thorough security requirements, or what have you. Using these processes in general tends to force simpler systems. Iterative development with clear thought out implementation per iteration etc.
The only industries that have good software practices are those that are regulated heavily enough for it to matter, see here medical, aviation, military etc.
Unfortunately the vast majority of software is not regulated in this way despite handling data that is potentially just as sensitive from a personal or even financial perspective.
At the end of the day most companies are motivated to produce software quickly and quality is second unless it's causing a reduction in velocity, even then this is simply treated as a debt that is paid down periodically to maintain velocity.
There are exceptions for things like banks that rely on the quality of software to avoid losing money, but we are talking in general here.
A brilliant example of what happens when you have sloppy security/bad incentives AND you underestimate the damage a breach would cause is the Ashley Madison situation. Many companies are in the same situation and have just been lucky enough to avoid a catastrophic data breach.
Sadly velocity is going to be valued over quality (which in turn means security) for the foreseeable future.
The big internet companies, like Google, Facebook etc, have no regulation on their code, yet adopt practices like code review.
Banks have pretty bad software quality, too. (I worked for one bank, and talked to lots of people.) Though that's a generalization: there's lots of places for software in a bank. The parts that directly handle the money tend to have less bugs emerging day to day, but that's more because of low velocity and operating within known parameters (so as not to trigger any lurking bugs in the edge cases).
For everyone else, software is an expense: it's something to be minimized and gotten over with as quickly as possible so they can direct their resources towards solving business problems in some other domain that actually brings in the cash.