Waterfall assumes that the project is complicated, ie not obvious, but certainly understandable, and predictable, and can be addressed linearly. As a consequence of this belief, it comes up with solutions that are totally reasonable in complicated domains. For example, construction is (to my knowledge) a complicated domain, so you might draw the blueprints, construct the structure, get the structure inspected. For software, that might be to specify the code (often called "architecture" and involving UML), hire the coders to implement the code, have the testers test the code. Seems totally reasonable.
The problem is that most projects are complex, not complicated, and this is especially true in software. In a complex domain, there are so many variables that your ability to predict how one thing is affected by another is very limited. Once you've solved a problem, it's fairly easy to look back at the path and see how you got to the solution, but from the starting spot, there may be several equally promising approaches to solve the problem. In a complex domain, you can't plan out a path to a solution, you may not even know what the solution is!
For example you want to make a Slack (internet chat) bot that lets one user send a link to another user. Turns out there's several ways to do almost that but no way to do exactly that, so the feature itself must change: either the link works for any number of users in a channel, or can only be used in a private 1-on-1 conversation. You sit down to format the bot's response thinking you're halfway done but in reality you're about to discover that the project has to pivot because of details in their API.
Now imagine you spent 3 years planning this application and the last 2 years coding, you've got another year left before the testers start testing it when all of a sudden, oops, turns out it's not possible because of this tiny little detail at the bottom. 5 years, tens of millions of dollars, hundreds of people, not a single user, the code never ran once, and finally the whole project gets scrapped.
This happened enough times to enough people for enough cost and frustration and death marches to meet release dates and hacks on hacks to just get it done and drop the mess in someone else's lap that people began to look for other ways of doing things. People who were exploring different ways of doing things wound up converging on some common practices, so they went up to the mountains and wrote a manifesto agilemanifesto.org with twelve principles agilemanifesto.org/principles.html
Since it addresses a real problem that many people were really experiencing, the adoption was "wildly in excess of anything [they] expected" (techbeacon.com/uncle-bob-martin-ag...).
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 assumes that the project is complicated, ie not obvious, but certainly understandable, and predictable, and can be addressed linearly. As a consequence of this belief, it comes up with solutions that are totally reasonable in complicated domains. For example, construction is (to my knowledge) a complicated domain, so you might draw the blueprints, construct the structure, get the structure inspected. For software, that might be to specify the code (often called "architecture" and involving UML), hire the coders to implement the code, have the testers test the code. Seems totally reasonable.
The problem is that most projects are complex, not complicated, and this is especially true in software. In a complex domain, there are so many variables that your ability to predict how one thing is affected by another is very limited. Once you've solved a problem, it's fairly easy to look back at the path and see how you got to the solution, but from the starting spot, there may be several equally promising approaches to solve the problem. In a complex domain, you can't plan out a path to a solution, you may not even know what the solution is!
For example you want to make a Slack (internet chat) bot that lets one user send a link to another user. Turns out there's several ways to do almost that but no way to do exactly that, so the feature itself must change: either the link works for any number of users in a channel, or can only be used in a private 1-on-1 conversation. You sit down to format the bot's response thinking you're halfway done but in reality you're about to discover that the project has to pivot because of details in their API.
Now imagine you spent 3 years planning this application and the last 2 years coding, you've got another year left before the testers start testing it when all of a sudden, oops, turns out it's not possible because of this tiny little detail at the bottom. 5 years, tens of millions of dollars, hundreds of people, not a single user, the code never ran once, and finally the whole project gets scrapped.
This happened enough times to enough people for enough cost and frustration and death marches to meet release dates and hacks on hacks to just get it done and drop the mess in someone else's lap that people began to look for other ways of doing things. People who were exploring different ways of doing things wound up converging on some common practices, so they went up to the mountains and wrote a manifesto agilemanifesto.org with twelve principles agilemanifesto.org/principles.html
Since it addresses a real problem that many people were really experiencing, the adoption was "wildly in excess of anything [they] expected" (techbeacon.com/uncle-bob-martin-ag...).