4 ms·

I see so much dissonance in this attitude. It's right here in your comment: > The stakeholders have no idea what they want And yet, you want to put together a

I see so much dissonance in this attitude. It's right here in your comment: > The stakeholders have no idea what they want And yet, you want to put together a project plan up front based on them telling you exactly what to build without assuming there will be sweeping changes? That makes no sense! Building iteratively recognizes this reality that people aren't sure what they want or need, rather than peevishly ignoring it. The goal is to figure out what would be valuable in a short period of time; if it isn't valuable at all, that's fine, it was not a huge investment and can just be thrown away; if it is valuable but not quite right or not as useful in its current form as it could be in a different form, but the change needed is large or fundamental, that's still fine, even sweeping changes are no big deal on top of something small; and if it's already valuable just the way it is, that's great, move on to the next iteration. This seems to make a lot of people uneasy, I guess because it provides no formula for answering the question of where things will stand in a year, or even in six months. But it honestly recognizes that nobody knows, rather than setting the expectation that where things will stand is exactly where they project plan says they will, with everyone inevitably getting mad that reality didn't match that plan, or worse, being exactly where the plan said you'd be, except the thing the plan called for was the wrong thing to build and the whole thing was a useless waste of time.

Sakos 3y ago
The issue stems more from how stakeholders and management don't know what they want, but they still expect tight and concrete deadlines. Either you have iterative development with space to explore ideas and solutions which will take longer, but might result in a cleaner, more robust design, or you focus on deliverables and deadlines with clearly defined specifications. You can't have it both ways.
- sanderjd 3y ago
  Oh I agree. My criticism here is for the widespread belief that people know what they want, and that certainly applies to management and other stakeholders. It's why I like working with management that has come up through the ranks of IC software development, because they have naturally internalized this lesson that they probably don't actually know exactly what they want up front, and are more likely to support the more humble path of small iterations. But of course you work on the project you have with the stakeholders you have!
nerdponx 3y ago
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. I never understood why software engineers had such a high tolerance for this shit. Is it because changes are technically possible at any point? 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. We should treat software engineering more like that. There's no reason we should allow product people to abuse the flexibility of software. You can still be agile, but you don't have to be at the beck and call of people whose preferences change with the direction of the wind.
- sanderjd 3y ago
  > 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?
js8 3y ago
You claim that "people not knowing what they need or want" is some objective reality, but I don't think it is. It seems to me that it is a symptom of top leadership unwillingness to commit to a clear goal. I also think you can do iterative development with having a clear long-term objective (requirements) in mind. I would even argue it helps a lot. I suggest looking up "What made Apollo a success" (https://ntrs.nasa.gov/citations/19720005243 https://ntrs.nasa.gov/citations/19720005243), they explain it quite well.
- sanderjd 3y ago
  Well, actually it was the comment I replied to that said "stakeholders don't know what they want". But I do agree with that commenter that it is usually the case. But people often seem to ascribe that to a failing of a person or group of people - "top leadership" in your comment - but I think it's essentially the same "failing" as predicting the future incorrectly. Of course lots of effort is put into forecasting as well, and effort put into requirement gathering is similarly valuable. But in both cases, investing in flexibility is a useful hedge against the likelihood that your original prediction was wrong. > I also think you can do iterative development with having a clear long-term objective (requirements) in mind. I would even argue it helps a lot. Personally, I don't think this is "iterative" in the same sense of the word. I recognize that it is still iterative and that there probably isn't a better word to use. But just chopping up a long list of static requirements into smaller chunks and doing them in some order is what project planners have done time immemorial, and is not the same conceptual idea as setting a vision and discovering detailed requirements toward that vision a small chunk at a time. It's that second approach that is the sense of "iterative" I was using. I certainly don't think it's the only way to do things, and I don't think it's a great fit for every project, but I wish more people were actually bought into the leap of faith required to let go of detailed up-front top-down planning and work in small iterations.
CM30 3y ago
Well I guess maybe my wording wasn't ideal. Sometimes it's 'what they want changes significantly through the development process due to outside factors'. Having time to iterate is good. Being able to experiment and figure out what's valuable is good. Being given a strict deadline, then halfway through being expected to chuck out nearly everything because the client brought the demo to the rest of the board and the latter didn't like it/chewed them out for it is perhaps not so great.
- sanderjd 3y ago
  Yes, but I'd argue that that bad thing is downstream of the implicit expectation people seem to have that people do and especially that they should know what they want, up front. In this example, the client thought they knew what the board wanted, but they didn't, and you thought you knew what the client wanted, but you couldn't possibly, because what they wanted was a thing the board would like, but they clearly didn't know what that was. It's a sticky wicket because of course time in front of the board is precious so you don't want to constantly run things by them and make them micro-manage, but I think the board would have probably chewed them out less if they had brought a tiny MVP (or even just a proof of concept) that hadn't required significant investment, and asked "here's what we have with almost no investment, here's our plan for the next small step, what do you think of this direction?".

Sakos 3y ago

The issue stems more from how stakeholders and management don't know what they want, but they still expect tight and concrete deadlines. Either you have iterative development with space to explore ideas and solutions which will take longer, but might result in a cleaner, more robust design, or you focus on deliverables and deadlines with clearly defined specifications. You can't have it both ways.

sanderjd 3y ago
Oh I agree. My criticism here is for the widespread belief that people know what they want, and that certainly applies to management and other stakeholders. It's why I like working with management that has come up through the ranks of IC software development, because they have naturally internalized this lesson that they probably don't actually know exactly what they want up front, and are more likely to support the more humble path of small iterations. But of course you work on the project you have with the stakeholders you have!

nerdponx 3y ago

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. I never understood why software engineers had such a high tolerance for this shit. Is it because changes are technically possible at any point? 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. We should treat software engineering more like that. There's no reason we should allow product people to abuse the flexibility of software. You can still be agile, but you don't have to be at the beck and call of people whose preferences change with the direction of the wind.

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

js8 3y ago

You claim that "people not knowing what they need or want" is some objective reality, but I don't think it is. It seems to me that it is a symptom of top leadership unwillingness to commit to a clear goal. I also think you can do iterative development with having a clear long-term objective (requirements) in mind. I would even argue it helps a lot. I suggest looking up "What made Apollo a success" (https://ntrs.nasa.gov/citations/19720005243 https://ntrs.nasa.gov/citations/19720005243), they explain it quite well.

sanderjd 3y ago
Well, actually it was the comment I replied to that said "stakeholders don't know what they want". But I do agree with that commenter that it is usually the case. But people often seem to ascribe that to a failing of a person or group of people - "top leadership" in your comment - but I think it's essentially the same "failing" as predicting the future incorrectly. Of course lots of effort is put into forecasting as well, and effort put into requirement gathering is similarly valuable. But in both cases, investing in flexibility is a useful hedge against the likelihood that your original prediction was wrong. > I also think you can do iterative development with having a clear long-term objective (requirements) in mind. I would even argue it helps a lot. Personally, I don't think this is "iterative" in the same sense of the word. I recognize that it is still iterative and that there probably isn't a better word to use. But just chopping up a long list of static requirements into smaller chunks and doing them in some order is what project planners have done time immemorial, and is not the same conceptual idea as setting a vision and discovering detailed requirements toward that vision a small chunk at a time. It's that second approach that is the sense of "iterative" I was using. I certainly don't think it's the only way to do things, and I don't think it's a great fit for every project, but I wish more people were actually bought into the leap of faith required to let go of detailed up-front top-down planning and work in small iterations.

CM30 3y ago

Well I guess maybe my wording wasn't ideal. Sometimes it's 'what they want changes significantly through the development process due to outside factors'. Having time to iterate is good. Being able to experiment and figure out what's valuable is good. Being given a strict deadline, then halfway through being expected to chuck out nearly everything because the client brought the demo to the rest of the board and the latter didn't like it/chewed them out for it is perhaps not so great.

sanderjd 3y ago
Yes, but I'd argue that that bad thing is downstream of the implicit expectation people seem to have that people do and especially that they should know what they want, up front. In this example, the client thought they knew what the board wanted, but they didn't, and you thought you knew what the client wanted, but you couldn't possibly, because what they wanted was a thing the board would like, but they clearly didn't know what that was. It's a sticky wicket because of course time in front of the board is precious so you don't want to constantly run things by them and make them micro-manage, but I think the board would have probably chewed them out less if they had brought a tiny MVP (or even just a proof of concept) that hadn't required significant investment, and asked "here's what we have with almost no investment, here's our plan for the next small step, what do you think of this direction?".