5 ms·

This 100%. The issue is that much of the time, project planning is done terribly. The stakeholders have no idea what they want, and will demand extra features/s

by CM30 3y ago

This 100%. The issue is that much of the time, project planning is done terribly. The stakeholders have no idea what they want, and will demand extra features/sweeping changes at seemingly random. Lots of edge cases are needed for things that probably shouldn't be done with this tool, but are being done so anyway. The designers often create designs that are at odds with the features needed, how the existing system works, what said stakeholders want, etc. The various teams developing parts of the system don't communicate well and build things in silos. Poorly thought out 'agile' processes end up trying to cram everything into a certain timeframe based on some questionably decided points score. Etc. For the most part, it's those types of issues that lead to a system not working as intended, or being buggy as hell. If you can get a good setup going where the requirements are clear and don't change and the people on the project communicate well and have full control over the process then things will work out fine. That's seemingly what happened in the source article.

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

by CM30 3y ago

sanderjd 3y ago

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?