Software quality/delay problems are coming from one source: constant changes

The discipline of software engineering is mostly about managing change, and the most impactful ideas in the field support this from the micro level to the macro level. For example, at the micro level immutable functional programming with modern type systems allow you to refactor code more confidently. At the macro level using agile processes instead of waterfall allow you to make larger changes with the same investment by breaking the change into many smaller deliverable pieces iteratively applied with the benefit of feedback. Other examples: modern source control, modern DevOps (CI / CD), microservices, OO-style design patterns, API or protocol design (backwards & forwards compatibility guarantees), data modeling. These don't all apply to game development, but I think the comparison is instructive.

Obviously change isn't the ONLY thing, even with a static set of requirements you have to build something that makes tradeoffs between various constraints (performance, cost, etc.). But it's much more common to be working in an environment that has frequent changes than one with static, known requirements, which is why this factor has been so influential in how we develop software.

With that in mind, saying that software quality and delays come from constant changes from game designers shouldn't be surprising. If this weren't such a hard issue, we wouldn't have spent so much of our collective effort creating ways of addressing it. Just like in bridge building we put a lot more effort into understanding the physics of different ways of holding up the cars instead of, say, what bridge paint colors most reduce the risk of accident.