5 ms·

> Why advocate for a poorer experience when it's possible to achieve a better one? > But it's clearly possible to make changes to software without a bunch of l

> Why advocate for a poorer experience when it's possible to achieve a better one? > But it's clearly possible to make changes to software without a bunch of lead time My argument is that it's often not possible, at least not in the way that non-programmers seem to think it is. There is lead time in delivering an updated product after requirements change. There is a positive relationship between the size of the change request and the amount of time/effort needed to adjust to the request. 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. So while there isn't a hard minimum like there is for planting new flowers, you cannot treat software as infinitely malleable unless you also have infinite resources. Nobody has infinite resources. At some point, design iteration must end. Iteration without convergence means that completion is impossible, and therefore project success is impossible. And even in the initial prototyping phase, change requests must be triaged (or rejected if necessary) given resource constraints.

sanderjd 3y ago
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.

sanderjd 3y ago

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.