[erikpukinskis]

It's because when you truly add a new capability to your toolset, like 100ms installs, or universal cross platform loading, this has ripple effects through every problem you solved before. Some things simply don't work in the new codebase, other things have regressed. Then you go back and one-by-one you fix everything to work in this new reality. This happens every time our aggregate software architecture gets a big new ability.

Of course if you're touching the same code over and over again, that's probably a sign you're not solving the problem well. Solving problems with a finality such that they don't have to be reopened again and again is the aim of good software engineering. That is true.

But in order to get there, you need to periodically add a major new capability—and thus a major new assumption—to your architecture. If you're not making these kinds of sweeping changes every now and then it's almost certain that you're not actually doing deep refactors that resolve longstanding challenges in lower energy ways.

Resistance to these kinds of sweeping changes amongst professional developers and their ambassadors at major platform companies is the reason why Windows, iOS, Oracle, and the like have stable interfaces and smaller audiences. On the web you don't need permission to write a whole new JavaScript framework, so people can take those first big steps, even though they are quite painful for the developer.