[naasking]

> Every waterfall project is secretly an iterative project because there's always a Phase 2 where the requirements get updated

This is a false equivalence. Waterfall is iterative in requirements but not in code. Changing the requirements document is much, much simpler than changing the code to conform to new requirements.

> The optimum amount of tech debt is not zero. Tech debt is a product of changing the product plan/vision/design in reaction to learning from customers. If you're not accruing tech debt then you're not learning from your users.

Not sure I agree with the implication "learning from users entails accruing technical debt". Technical debt is a rough measure of the inherent resistance of your program to adapt to customer requirements. Some architectures are flexible enough that you could learn how to configure the architecture differently based on what you've learned from users, but I don't see how that necessarily entails the addition of technical debt, ie. as a rule.

[marcus_holmes]

If the requirements change, then so must the code. The code you wrote for phase 1 cannot (by definition) include the changes needed for phase 2. Especially because you don't discover the changes needed for phase 2 until partway through phase 1.

Writing code so that it can be easily changed to conform to new requirements is a trade-off, like everything. You will incur some cost to do this, probably longer dev times. In many cases this trade-off is not worth it.

And in my experience, shipping a new feature faster is always the goal. Dealing with the tech debt incurred is a tomorrow problem, and tomorrow we will have more funding/staff/time to deal with it than we do today. It's not always true, of course, but that's the attitude generally.