I see a comparable effect at work in the software industry esp. in teams dealing with aging software. Team members or whole teams can get used to flaws or ‘minor’ inconveniences in the software, esp. the build and development process until the process slows down to a level where any change takes ages because all steps of the development process have accumulated enough of these invisible problems to hinder any real progress. And the developers not feeling any real pain and have plausibly sounding excuses (“the build just takes that long to compile our large application”, “the deployment just requires these manual copy steps”, “we have to first create/update/close all the bugtracker entries”...). For the code-base itself there is the concept of Technical Debt, but this problem seems to go deeper because it becomes an indeed invisible part of the organizational process. It is comparable to the problem of Uniformly Slow Code where no simple hot spots can be cured either.
I see a comparable effect at work in the software industry esp. in teams dealing with aging software. Team members or whole teams can get used to flaws or ‘minor’ inconveniences in the software, esp. the build and development process until the process slows down to a level where any change takes ages because all steps of the development process have accumulated enough of these invisible problems to hinder any real progress. And the developers not feeling any real pain and have plausibly sounding excuses (“the build just takes that long to compile our large application”, “the deployment just requires these manual copy steps”, “we have to first create/update/close all the bugtracker entries”...). For the code-base itself there is the concept of Technical Debt, but this problem seems to go deeper because it becomes an indeed invisible part of the organizational process. It is comparable to the problem of Uniformly Slow Code where no simple hot spots can be cured either.