"Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality."
This is the biggest issue, software is seen as something that is built, not something that has to be maintained, improved and extended.
It's amazing how companies can pour tens of millions into the build step and lose that investment by not maintaining and improving it.
They don't lose the investment, though. They put it in back-burner mode where very little effort is expended, re-org the team to work on something else, and the software continues to generate revenue. It's a pattern I've seen a lot.
Another one of those real-world insights I've had is a variant of Conway's Law... the software built by a team reflects that team's communication structures, but if you dissolve the team and hand maintenance to someone else, they'll never make sense of the original code, because it doesn't match the communication structure of the new team.
Every day it spends on the back burner it gets less and less maintainable though. The libraries and technology it's built with get outdated, the systems it has to interact with keep evolving and the knowledge about the system disappears.
Then when they need to update it (say for a new version of IE) they can't find anyone competent to work on it because no one competent wants to work on such an outdated POS. A simple bug fix or added may involve upgrading a tonne of dependencies and code changes in the project is effectively dead.
This is the biggest issue, software is seen as something that is built, not something that has to be maintained, improved and extended.
It's amazing how companies can pour tens of millions into the build step and lose that investment by not maintaining and improving it.