4 ms·

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).

RogerL 13y ago
I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'. What was our mantra? "Design a little, code a little, test a little". Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision. So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process. To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on. I'm old.
- ternaryoperator 13y ago
  >"Design a little, code a little, test a little". That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1] >The details vary, to be sure, but the fundamentals remain the same. I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is. [1] https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model
  - emmelaich 13y ago
    People should stop using the term waterfall to describe any real process. It's only been used to describe a fictitious cartoon of a process, purely for the sake of their argument. That wikipedia article is a bit of a mess, but read the article at footnote 7: http://www.idinews.com/waterfall.html "There's no such thing as the Waterfall Approach! (and there never was)"
    - masomenos 13y ago
      If only that were true! My first employer was a large organization that explicitly embraced the waterfall methodology that we all rightfully deride.
    - jasonwocky 13y ago
      There may have been no capital-W Waterfall approach, but implying that projects weren't routinely being run in a waterfall-esque, staged-handoff fashion smacks of revisionism. I was there. I was on those projects. They existed, and unless everything went perfectly according to plan, they were messes.

RogerL 13y ago

I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'. What was our mantra? "Design a little, code a little, test a little". Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision. So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process. To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on. I'm old.

ternaryoperator 13y ago
>"Design a little, code a little, test a little". That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1] >The details vary, to be sure, but the fundamentals remain the same. I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is. [1] https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model
- emmelaich 13y ago
  People should stop using the term waterfall to describe any real process. It's only been used to describe a fictitious cartoon of a process, purely for the sake of their argument. That wikipedia article is a bit of a mess, but read the article at footnote 7: http://www.idinews.com/waterfall.html "There's no such thing as the Waterfall Approach! (and there never was)"
  - masomenos 13y ago
    If only that were true! My first employer was a large organization that explicitly embraced the waterfall methodology that we all rightfully deride.
  - jasonwocky 13y ago
    There may have been no capital-W Waterfall approach, but implying that projects weren't routinely being run in a waterfall-esque, staged-handoff fashion smacks of revisionism. I was there. I was on those projects. They existed, and unless everything went perfectly according to plan, they were messes.