> Or engage with stakeholders early in the process and work with them to actually elicit something resembling a stable set of preferences. Maybe you need to even iterate through a couple rounds of prototypes to figure out what they actually want.
What I think is that this is right, except the expectation should just be that ideally you keep that iteration going indefinitely, instead of saying, "ok, now that we've done these couple rounds of prototypes, we now definitely know everything about what your preferences are!".
That's more likely to be true after a couple rounds of iteration of prototypes, which is good, but still unlikely to be true.
> For example, if I order flowers for a wedding, I need to order at least a few months in advance depending on the time of year, because flowers are a seasonal agricultural product. And I can't change my order once it's locked in because they can't go back in time and plant more flowers.
Yes, it's because it would be a lot better if you could immediately switch the order. Wedding planning, and many other things, would be a much better if everything didn't require locking in decisions months in advance.
Why advocate for a poorer experience when it's possible to achieve a better one? Sure, if you want to charge less for a process that asks for all requirements up front with no changes allowed later, because that's less valuable, and a higher rate for an iterative process that responds swiftly to changes in direction, because that's more valuable, then that would make sense.
But it's clearly possible to make changes to software without a bunch of lead time - you don't have to wait for seeds to grow or send a manuscript to the printer or blueprints to a manufactures - so why would we artificially mimic those worse experiences?
> 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.
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.
What I think is that this is right, except the expectation should just be that ideally you keep that iteration going indefinitely, instead of saying, "ok, now that we've done these couple rounds of prototypes, we now definitely know everything about what your preferences are!".
That's more likely to be true after a couple rounds of iteration of prototypes, which is good, but still unlikely to be true.
> For example, if I order flowers for a wedding, I need to order at least a few months in advance depending on the time of year, because flowers are a seasonal agricultural product. And I can't change my order once it's locked in because they can't go back in time and plant more flowers.
Yes, it's because it would be a lot better if you could immediately switch the order. Wedding planning, and many other things, would be a much better if everything didn't require locking in decisions months in advance.
Why advocate for a poorer experience when it's possible to achieve a better one? Sure, if you want to charge less for a process that asks for all requirements up front with no changes allowed later, because that's less valuable, and a higher rate for an iterative process that responds swiftly to changes in direction, because that's more valuable, then that would make sense.
But it's clearly possible to make changes to software without a bunch of lead time - you don't have to wait for seeds to grow or send a manuscript to the printer or blueprints to a manufactures - so why would we artificially mimic those worse experiences?