Another contributing factor?
First, a dinosaur alert. I am not older than dirt, but I am older than Fortran, Cobol, and programming in assembly language.
Enterprises that I am familiar with are having increasing difficulty maintaining good synchronization among development, test, and live operational environments.
The root causes are too many and tedious to list here. Most, not all, of them essentially come down to a drive to reduce cost and avoid accountability. One key result is the rush adopt the use of commercial-off-the-self technology (COTS) and dependence on third party vendors.
Systems comprise a hodgepodge of special-purpose application code, third party Apps, network OS, and database management software (I'm sure I missed a few.) The special-purpose application code barely warrants the name. As a practical matter, the "designer" is stuck with whatever canned functions their COTS "development" system provides. (Think pre-formatted Powerpoint, just less sightly and less creative.)
Between patching, patching patches and keeping ahead of hackers, third party building blocks are updated every whipstitch. The third party COTS is proprietary, and systems developers/owners cannot afford to pay for IP rights that would provide the level of technical specificity needed to understand the effects observed. The third party vendors are not price gouging--the IP are the crown jewels.
The problem is that changes have unintended consequences.
That bears repeating. Changes have unintended consequences.
Database software that we have no reason to expect to affect an application does. The document that has been rendering quite nicely for several years, suddenly throws a rod and comes out in 6-point type.
It is not simply that the alleged economic benefits of COTS are not being realized. In the case of one system that I have been personally involved configuration management at the user system level has become virtually impossible. Testing is practically meaningless. We can test the system, but cannot guarantee that the configuration as deployed matches what we tested. In fact when we run an extensive User Acceptance Test, we cannot guarantee that the configuration was stable for the duration of the test.
Make no mistake, having had to watch a government enterprise make a hash of a system that we successfully operated for years pre-FISMA, I have a severely jaundiced view of government IT procurement practices. But, being objective, I doubt I could do any better if I had to work under the same constraints.
The explosive growth in real hardware performance over the last three decades has let us det away with abandoning fundamental principles of computer programming. Like tight, efficient code is better than bloatware. We are getting to pay for the results.
A closing note: The evolution of the technology has served the consumer mass market superbly. I enjoy computing capabilities that I could never have imagined sorting through my deck of Hollerith cards hunting for the infamous infinite "do loop." The mistake is presuming that because the technology is ideal for fun and games it can be put to serious work with minimal cost and effort. It ain't necessarily so.
One old man's observations, for what they're worth.