We largely agree. I certainly am not advocating for pretending it is possible to do impossible things. But I am advocating for taking advantage of malleability to the event that it does exist in reality.
But I'll quibble with a couple things. Or rather, I'll just put forward that I have a different perspective on them, while fully understanding where you (and I think most people) are coming from with your differing perspective:
> A complete design overhaul will typically require a substantial code rewrite. That takes time, and taxes the sanity of the people writing the code. At some point, employee morale and the risk of them quitting for other jobs becomes a resource to that you need to manage.
I think people would have their sanity less taxed if they "just" had more realistic expectations. I think what rightly frustrates people is being asked to redo things on unrealistic timelines or without appropriate compensation. But those are their own separate problems. Absent those issues it really should not be frustrating to make foundational changes in light of things that have been learned about what would make the system more useful. It should be expected as a nearly inevitable part of the process.
> At some point, design iteration must end. Iteration without convergence means that completion is impossible, and therefore project success is impossible.
I don't think so. I think the most successful software projects don't reach "completion" but rather iterate indefinitely. The iphone has not reached completion, and is nonetheless very successful.
But I'm guessing you're thinking of fixed term project work as a consultant / contractor. If so, this is one reason why I frankly don't think that's a very good model for building software. At the very least, I think the expectation that iteration will continue to be useful indefinitely should be built into the contract, with some way for a client to decide that they are satisfied and decide to delay or not pursue further iterations. But I think an expectation of "completion" is a recipe for frustration on all sides.
But I'll quibble with a couple things. Or rather, I'll just put forward that I have a different perspective on them, while fully understanding where you (and I think most people) are coming from with your differing perspective:
> A complete design overhaul will typically require a substantial code rewrite. That takes time, and taxes the sanity of the people writing the code. At some point, employee morale and the risk of them quitting for other jobs becomes a resource to that you need to manage.
I think people would have their sanity less taxed if they "just" had more realistic expectations. I think what rightly frustrates people is being asked to redo things on unrealistic timelines or without appropriate compensation. But those are their own separate problems. Absent those issues it really should not be frustrating to make foundational changes in light of things that have been learned about what would make the system more useful. It should be expected as a nearly inevitable part of the process.
> At some point, design iteration must end. Iteration without convergence means that completion is impossible, and therefore project success is impossible.
I don't think so. I think the most successful software projects don't reach "completion" but rather iterate indefinitely. The iphone has not reached completion, and is nonetheless very successful.
But I'm guessing you're thinking of fixed term project work as a consultant / contractor. If so, this is one reason why I frankly don't think that's a very good model for building software. At the very least, I think the expectation that iteration will continue to be useful indefinitely should be built into the contract, with some way for a client to decide that they are satisfied and decide to delay or not pursue further iterations. But I think an expectation of "completion" is a recipe for frustration on all sides.