4 ms·

Pure waterfall as it's depicted by Agile consultants was never a thing. Think about it, how could you possibly code an entire app and only then debug it? Howev

Pure waterfall as it's depicted by Agile consultants was never a thing. Think about it, how could you possibly code an entire app and only then debug it? However, there was a waterfall-like process that was widely used. After getting the reqs and design in place, you started coding and you mostly coded. You would compile as you went along and made sure that your code worked on the handful of tests you put together as you went along. When the app was mostly coded, you then started more serious testing: writing more elaborate tests and verifying functionality. This step often highlighted buried errors that you then spent time debugging, writing additional tests, and so on. So, the biggest innovation in Agile was the latter's orientation towards developer testing concurrently with coding. Which, of course, has had many other ramifications. While the old way of doing things might sound klunky by today's standards, when done right it actually worked better than its reputation. Because devs hated spending hours in the debugger, they tended to code very carefully. The concept of "let's code this and run it through some tests to validate it" was unknown. Rather you coded so that you were pretty much sure that what you were writing worked properly if it compiled without error.

gnaritas 10y ago
> Pure waterfall as it's depicted by Agile consultants was never a thing. Yes it was. > Think about it, how could you possibly code an entire app and only then debug it? Which is why programmers hate waterfall so much, but you're absolutely wrong to think this isn't exactly what was being attempted. Time and time again, management in an attempt to cut the cost of programming time, thought the way to do it was to first build specification for everything and try and prototype the entire app up front, storyboard every screen, build out mountains of specs because naturally they think that's how you build things, with detailed blueprints so all the decisions have already been made. They couldn't be more wrong, but it's certainly the most natural way to think if you aren't a programmer and don't know better. > So, the biggest innovation in Agile was the latter's orientation towards developer testing concurrently with coding. Which, of course, has had many other ramifications. Agile in general had nothing to do with testing, the big change in agile was removing the big design up front, the specs and meetings and months spent planning something before being developed. Some agile methods like extreme programming certainly had testing as a big part of their process, but what differentiated agile from waterfall was introducing iterative programming where work was done in short week or two cycles and then delivered whereas waterfall wastes enormous time trying to nail down details that simply ended up being wrong come programming time. tldr; agile is not about testing, it's about iterative development in short cycles with little planning and always has been and that's what made it different from waterfall; no "Big Design Up Front".
- ternaryoperator 10y ago
  "Pure waterfall as it's depitected by Agile consultants was never a thing." This is correct. The first paper to describe a stepwise model was by Royce in 1970 [1]. The model he is describing is hypothetical and does not use the term Waterfall. The first use of the word "waterfall" (including the quotation marks) is from 1976 [2] and specifically refers to [1], the hypothetical model. In [2], the writers specifically state that "so few" projects fit this scheme. If you were programming in the 80s and early 90s, you would know that no one in programming ever referred to a "waterfall" model. Even Kent Beck's seminal book on XP, written in 2000, describes many failures of software development in those days, but he does not once use the word Waterfall. So, in summary: the paper that supposedly describes it describes a hypothetical system; the paper that first uses the term mentions how little the model is used; the term wasn't used by people during the era it was supposedly most popular; and the folks who initiated the new generation of software dev don't refer to the model. I think it's safe to say that it was not a thing. Or, to be more accurate, if it was a thing, it was never the thing it became until the Agile consultants used is as a strawman. [1] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate... [2] https://goo.gl/eYLBN7 https://goo.gl/eYLBN7
  - bandushrew 10y ago
    The term "Waterfall" was not applied. but it absolutely was very common to use the process that it implies. many man-years of gathering requirements, building lists of features, interrogating stakeholders. people knew they would never get a second chance to get what they wanted, so they would throw every feature in that they could think of. Then the developers would build it. more man years building. mostly they tested as they went along, but....different features and areas of the app were often build in isolation, so the most you could say was that you had tested what you had built. the stakeholders were consulted with screenshots, and sometimes the app, but the Big Fear was new features and additional requirements (which would cause massive contractual headaches) so any contact was VERY carefully controlled. Also it was assumed every project was massively valuable IP, so detailed designs and features were held very close to the chest..again, any contact was VERY carefully controlled. Eventually, after months or years of effort the various parts of the app would be "merged". omg the cluster fuck that would occur, the compromises, and arguments, the agonizing... ..then more testing.. Once that was completed the brilliant new creation would be seriously unveiled to the users to cheers and relief. Finally, the contractual battles would begin as the paying company realised they had asked for entirely the wrong thing, and the development company tried desperately to cover their ass and make a profit. The single biggest problem that Agile fixes isn't the testing, its the disconnect between what the client wanted and what the developers actually deliver.
GBond 10y ago
This thread makes me feel old.

gnaritas 10y ago

> Pure waterfall as it's depicted by Agile consultants was never a thing. Yes it was. > Think about it, how could you possibly code an entire app and only then debug it? Which is why programmers hate waterfall so much, but you're absolutely wrong to think this isn't exactly what was being attempted. Time and time again, management in an attempt to cut the cost of programming time, thought the way to do it was to first build specification for everything and try and prototype the entire app up front, storyboard every screen, build out mountains of specs because naturally they think that's how you build things, with detailed blueprints so all the decisions have already been made. They couldn't be more wrong, but it's certainly the most natural way to think if you aren't a programmer and don't know better. > So, the biggest innovation in Agile was the latter's orientation towards developer testing concurrently with coding. Which, of course, has had many other ramifications. Agile in general had nothing to do with testing, the big change in agile was removing the big design up front, the specs and meetings and months spent planning something before being developed. Some agile methods like extreme programming certainly had testing as a big part of their process, but what differentiated agile from waterfall was introducing iterative programming where work was done in short week or two cycles and then delivered whereas waterfall wastes enormous time trying to nail down details that simply ended up being wrong come programming time. tldr; agile is not about testing, it's about iterative development in short cycles with little planning and always has been and that's what made it different from waterfall; no "Big Design Up Front".

ternaryoperator 10y ago
"Pure waterfall as it's depitected by Agile consultants was never a thing." This is correct. The first paper to describe a stepwise model was by Royce in 1970 [1]. The model he is describing is hypothetical and does not use the term Waterfall. The first use of the word "waterfall" (including the quotation marks) is from 1976 [2] and specifically refers to [1], the hypothetical model. In [2], the writers specifically state that "so few" projects fit this scheme. If you were programming in the 80s and early 90s, you would know that no one in programming ever referred to a "waterfall" model. Even Kent Beck's seminal book on XP, written in 2000, describes many failures of software development in those days, but he does not once use the word Waterfall. So, in summary: the paper that supposedly describes it describes a hypothetical system; the paper that first uses the term mentions how little the model is used; the term wasn't used by people during the era it was supposedly most popular; and the folks who initiated the new generation of software dev don't refer to the model. I think it's safe to say that it was not a thing. Or, to be more accurate, if it was a thing, it was never the thing it became until the Agile consultants used is as a strawman. [1] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate... [2] https://goo.gl/eYLBN7 https://goo.gl/eYLBN7
- bandushrew 10y ago
  The term "Waterfall" was not applied. but it absolutely was very common to use the process that it implies. many man-years of gathering requirements, building lists of features, interrogating stakeholders. people knew they would never get a second chance to get what they wanted, so they would throw every feature in that they could think of. Then the developers would build it. more man years building. mostly they tested as they went along, but....different features and areas of the app were often build in isolation, so the most you could say was that you had tested what you had built. the stakeholders were consulted with screenshots, and sometimes the app, but the Big Fear was new features and additional requirements (which would cause massive contractual headaches) so any contact was VERY carefully controlled. Also it was assumed every project was massively valuable IP, so detailed designs and features were held very close to the chest..again, any contact was VERY carefully controlled. Eventually, after months or years of effort the various parts of the app would be "merged". omg the cluster fuck that would occur, the compromises, and arguments, the agonizing... ..then more testing.. Once that was completed the brilliant new creation would be seriously unveiled to the users to cheers and relief. Finally, the contractual battles would begin as the paying company realised they had asked for entirely the wrong thing, and the development company tried desperately to cover their ass and make a profit. The single biggest problem that Agile fixes isn't the testing, its the disconnect between what the client wanted and what the developers actually deliver.

GBond 10y ago

This thread makes me feel old.