2 ms·

Of course "anecdotal experiences" are evidence. Yes, they're messy, and may not be applicable to other circumstances, but they're certainly informative. I'm pr

Of course "anecdotal experiences" are evidence. Yes, they're messy, and may not be applicable to other circumstances, but they're certainly informative. I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process. But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations.

crimsonalucard 7y ago
>Of course "anecdotal experiences" are evidence. You're right. It is evidence. This is an obvious fact that I mis-represented on accident. Let me rephrase for clarity: "This persons anecdotal evidence is not good enough or unbiased enough to qualify as evidence to be used to arrive at a conclusion" >I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process. Ok let me rephrase for more clarity in case people don't have the ability to know that by "designing" a bridge I can mean "build" and "deploy" as well. "Airplanes and bridges are designed and built using waterfall." >But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations. This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design. It leads to shorter turn around and cheaper costs. With the small expense of 1 or 2 plane crashes. If you can afford a plane crash go agile, if you want to build something correctly go waterfall.
- aeorgnoieang 7y ago
  > This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design. A lot of software (that's often written about) can be tested 'in production' with fairly minor consequences in the event of 'failures'. That's an obvious difference between developing or maintaining software versus something like airplanes. But testing or validating the changes made in short iterations is important regardless. Agile stresses the utility of short iterations precisely so the changes in each iteration can be tested and validated ASAP. Whereas in a waterfall methodology, a larger set of changes, i.e. changes that would in agile be split among a number of iterations, is tested or validated together. And the more changes that end up being tested together, the larger the risk is that those changes, and more of them, will need to be scrapped or redone. The problem with the "MAX" changes of the 737 MAX seems more due to those changes not being tested or validated with the relevant users, i.e. pilots, at all before being 'released'. Yes, the flawed (or incorrect) reasoning was that the changes were relatively minor and thus didn't warrant the regulatory requirements for 'significant' changes. But that doesn't seem to have anything to do with how the changes were developed, whether their methodology was agile or waterfall (or anywhere in between). Obviously you're more likely 'to have a bad time' if you don't respond to, let alone seek, feedback from users about the changes you're making.

crimsonalucard 7y ago

>Of course "anecdotal experiences" are evidence. You're right. It is evidence. This is an obvious fact that I mis-represented on accident. Let me rephrase for clarity: "This persons anecdotal evidence is not good enough or unbiased enough to qualify as evidence to be used to arrive at a conclusion" >I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process. Ok let me rephrase for more clarity in case people don't have the ability to know that by "designing" a bridge I can mean "build" and "deploy" as well. "Airplanes and bridges are designed and built using waterfall." >But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations. This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design. It leads to shorter turn around and cheaper costs. With the small expense of 1 or 2 plane crashes. If you can afford a plane crash go agile, if you want to build something correctly go waterfall.

aeorgnoieang 7y ago
> This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design. A lot of software (that's often written about) can be tested 'in production' with fairly minor consequences in the event of 'failures'. That's an obvious difference between developing or maintaining software versus something like airplanes. But testing or validating the changes made in short iterations is important regardless. Agile stresses the utility of short iterations precisely so the changes in each iteration can be tested and validated ASAP. Whereas in a waterfall methodology, a larger set of changes, i.e. changes that would in agile be split among a number of iterations, is tested or validated together. And the more changes that end up being tested together, the larger the risk is that those changes, and more of them, will need to be scrapped or redone. The problem with the "MAX" changes of the 737 MAX seems more due to those changes not being tested or validated with the relevant users, i.e. pilots, at all before being 'released'. Yes, the flawed (or incorrect) reasoning was that the changes were relatively minor and thus didn't warrant the regulatory requirements for 'significant' changes. But that doesn't seem to have anything to do with how the changes were developed, whether their methodology was agile or waterfall (or anywhere in between). Obviously you're more likely 'to have a bad time' if you don't respond to, let alone seek, feedback from users about the changes you're making.