[javajosh]

The reason it's hard to refactor to simplicity is that one must feel free to modify foundational assumptions, and the repercussions of that change are both hard to implement (you must recapitulate all following changes with the new assumption) and test. By "foundational assumption" I mean architecture at the high level, and general code organization at the lower level. It is the "second system" problem, writ small but many times over.

Given that code grows over time in accordance with selection pressure, these lateral, foundational changes are always going to be difficult because recapitulating the following growth in general takes the same amount of time as the original system took to grow. The irony is that if that system is making money, it is even LESS likely that the will to simplify it will arise; if the system doesn't make money, then there will be neither will nor resources to try it.

"Physics progresses one funeral at a time", Planck's Principle [1], applies here. Software gets simpler but not laterally within a working project; it only gets simpler with new projects. Luckily software devs seem more open-minded than physicists so we can progress faster than funerals, but not arbitrarily so.

1 - https://en.wikipedia.org/wiki/Planck%27s_principle