Waterfall is never done right, though. It assumes infinite foresight and precision planning that must never fail or falter.
Who says Agile done right includes no planning? As an organization, you still need to do requirements analysis and prioritization, only Agile gives you permission to continually reassess and adapt to changing goals and market conditions without calling that a failure.
Finally, "Nowadays ... we write software and it's thrown away ... rewritten or refactored." Heck, yeah! That's a feature not a bug. Not only do requirements change and new technologies come along but the truest statement I know in software is "Good software is written. Great software is re-written." Once you've used software in production for a while, why wouldn't it make infinite sense to eventually rewrite parts that aren't working well and hone and expand parts that are proving indispensable? Best of all, Agile plus Continuous Integration lets you "improve in-place", A-B test and innovate in a way that Waterfall could never do without shutting down the whole assembly line and waiting for the organization to gear up for the next big push.
Once again, I must disagree. If this were the case, we would have never shipped a single usable software project prior to the invention of Agile. In fact, not only was software shipped, but some of that same software is still in use, and sometimes is more stable and reliable than some of its modern equivalents. So, Waterfall cannot be unilaterally altogether incompatible with completing a project.
It assumes infinite foresight and precision planning that must never fail or falter.
The way it is usually done, yes. Waterfall has issues, many of which Agile attempted to address.
That said, I've seen many of the same assumptions and mistakes made with Agile.
In reality: both methods would theoretically work well, but for human folly. I've used both successfully, and (more often), I've cherry-picked from both techniques (and others besides) to tailor the exact methodology needed for a single project.
When it comes to methodologies, anytime anyone says "X always works" or "X never works", that demonstrates they have failed to understand the vast majority of components in the problem they're trying to solve. (That's not a personal attack; I just find that to be universally true.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Waterfall is never done right, though. It assumes infinite foresight and precision planning that must never fail or falter.
Who says Agile done right includes no planning? As an organization, you still need to do requirements analysis and prioritization, only Agile gives you permission to continually reassess and adapt to changing goals and market conditions without calling that a failure.
Finally, "Nowadays ... we write software and it's thrown away ... rewritten or refactored." Heck, yeah! That's a feature not a bug. Not only do requirements change and new technologies come along but the truest statement I know in software is "Good software is written. Great software is re-written." Once you've used software in production for a while, why wouldn't it make infinite sense to eventually rewrite parts that aren't working well and hone and expand parts that are proving indispensable? Best of all, Agile plus Continuous Integration lets you "improve in-place", A-B test and innovate in a way that Waterfall could never do without shutting down the whole assembly line and waiting for the organization to gear up for the next big push.
Once again, I must disagree. If this were the case, we would have never shipped a single usable software project prior to the invention of Agile. In fact, not only was software shipped, but some of that same software is still in use, and sometimes is more stable and reliable than some of its modern equivalents. So, Waterfall cannot be unilaterally altogether incompatible with completing a project.
The way it is usually done, yes. Waterfall has issues, many of which Agile attempted to address.
That said, I've seen many of the same assumptions and mistakes made with Agile.
In reality: both methods would theoretically work well, but for human folly. I've used both successfully, and (more often), I've cherry-picked from both techniques (and others besides) to tailor the exact methodology needed for a single project.
When it comes to methodologies, anytime anyone says "X always works" or "X never works", that demonstrates they have failed to understand the vast majority of components in the problem they're trying to solve. (That's not a personal attack; I just find that to be universally true.)