5 ms·

Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limit

Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limited to government or very large corporations. Scrum arrived to slay a mythical beast.

MattPalmer1086 4y ago
I agree waterfall did not really exist in most places which is why I called it pseudo waterfall. But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.
- bdefore 4y ago
  There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs. What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering. Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.
  - MattPalmer1086 4y ago
    Sounds painful. I remember I did have to field questions from management on why one teams velocity wasn't "as good" as another's. They seemed to think it was some kind of globally objective measure rather than something particular to each team and their estimations.
    - bdefore 4y ago
      Your example has always been a common conversation. And a bit like The Neverending September, at some point the training became overwhelming. This misunderstanding about velocity has become prevalent, you could maybe say more common than its intention as a tool. There was a time when software teams didn't meticulously ticket and estimate everything. Hard for some to fathom, but stuff got done if you worked with honorable craftsman. Just differently. #noestimates feels very long ago. Sounds like you moved on wisely. Aberrations like these vary of course, but along the rise of large tech giants that demand alignment and are threatened by autonomy, it's become more de facto. It's sad to see small teams take it as a given for how things are done. I genuinely think it deforms and delays the solutions they're trying to make for their customers.
      - MattPalmer1086 4y ago
        Sadly, this constant push to measure and control all processes and tasks infects everything, not just development. Enterprise software is appalling at imposing workflows on everything in sight, and they always have pretty graphs and reports for management. I feel quite strongly that software should serve humans, rather than the other way around. These tools do not exist to help you get your job done, they make you its servant. Imagine how much more productive we could be if we had tools designed to actually help us. Management could still get nice reports, but some manager might have to knock up a spreadsheet. I can dream...
        gmfawcett 4y ago
        Please dream out loud. :) What would those tools look like?
        MattPalmer1086 4y ago
        I can think of some qualities those tools would have. Ease of use, focused simplicity. Interactions should be voluntary, not enforced by a workflow system. Usage metrics shouldn't be exposed outside its users, giving them flexibility to use it however makes sense for them.
- eesmith 4y ago
  The author points to Microsoft as a typical example of corporate programming in the 1990s. Yet Microsoft wasn't using a (pseudo)waterfall development model. Quoting Steve McConnell in "Rapid Development (1996) Page 271: ] In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale. As I've pointed out before, I've read about software development projects at Apple, Be, Commodore, Data General, id, Infocom, Microsoft, VisiCorp and others. None were using (pseudo)waterfall. I therefore agree with bdefore that it seems to have been "far from ubiquitous and mostly limited to government or very large corporations", and that the era of waterfall was a mythical beast.
  - MattPalmer1086 4y ago
    I guess it depends where you worked. I certainly don't claim it was ubiquitous, but I personally saw it at a start up and a small software house. Also government, for sure!
    - sgt101 4y ago
      I saw it at a local council (serving ~300k people) & a small gas (as in methane delivery) company as well as at a very large telco and in government/defence. It may not have been ubiquitous but it was definitely everywhere I worked.
      - eesmith 4y ago
        Yes, "Rapid Development" lists a dozen or more approaches, including iterative prototyping and (modified) waterfall, with pros and cons of each one. My issue with the standard Agile story repeated here is the lack of any mention of pre-Agile approaches other than waterfall. Take: "Rather than clearing the way for software developers to build, waterfall gummed up the works with binders of paperwork and endless meetings." Why is there no mention of any other approach? We can easily point to the Macintosh project, which took 5 years (1979 to 1984). Yet, no waterfall there. Or, take a closer look at: "Peter Varhol, a technology industry consultant, estimates that in the early 1990s, the average application took three years to develop, from idea to finished product." (That's shorter than the Macintosh project.) What does that mean? Which industry? What kind of applications? Clearly a lot of "log cabin" PC applications are excluded from that list - just think of all the DB2 and VB applications people wrote in that era. And video games.
- swagtricker 4y ago
  Yes. This bullshit you describe was real. I remember having managers in 1998 using Microsoft Project and HUGE plotters that were used for nothing but printing out massive Gantt charts. And, of course, having DAILY meeting when we were behind so that our manager could show with great accuracy how behind we were - and complain he needed more people to manage so he could build his fiefdom.
- legulere 4y ago
  Waterfall also consists of those phases. One core idea of agile is instead of a big design up front to iterate those phases as fast as possible because often the requirements are not clear from the beginning and you have to see if your ideas bring value to the stakeholders. The problem is that not all tasks can be done in a short time and sometimes need more planning. Planning is often neglected in agile environments. In some environments you also know the requirements beforehand (because they stem from the law for instance), agile development does not work there.
  - MattPalmer1086 4y ago
    I completely agree. In my early agile training, the instructor stated it was good for developing where requirements were unclear or responding to small feature requests quickly, due to the fast iterative approach with feedback. He also said that agile was not a substitute for planning. I guess those lessons weren't learned by everyone...
  - SAI_Peregrinus 4y ago
    Yep, the design phase shouldn't be an exclusive OR between a large-scale design & small-scale designs with iteration. It should be both: plan the large-scale architecture, marking the bits which are unknown, then iteratively design & build to fill out the unknowns & build the rest of the design. It's a recursive process. solve([problems]) 1. Define car(problems). 2. Plan a solution. 3. Implement the solution. 4. Test the solution. 5. Document the results. Add any problems discovered to the list. 6. solve(cdr(problems))
singron 4y ago
It's funny to me that one of the original descriptions of waterfall is actually something we might consider agile: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... It augments the naive waterfall with continual testing and customer feedback among other things that might surprise you.

MattPalmer1086 4y ago

I agree waterfall did not really exist in most places which is why I called it pseudo waterfall. But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.

bdefore 4y ago
There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs. What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering. Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.
- MattPalmer1086 4y ago
  Sounds painful. I remember I did have to field questions from management on why one teams velocity wasn't "as good" as another's. They seemed to think it was some kind of globally objective measure rather than something particular to each team and their estimations.
  - bdefore 4y ago
    Your example has always been a common conversation. And a bit like The Neverending September, at some point the training became overwhelming. This misunderstanding about velocity has become prevalent, you could maybe say more common than its intention as a tool. There was a time when software teams didn't meticulously ticket and estimate everything. Hard for some to fathom, but stuff got done if you worked with honorable craftsman. Just differently. #noestimates feels very long ago. Sounds like you moved on wisely. Aberrations like these vary of course, but along the rise of large tech giants that demand alignment and are threatened by autonomy, it's become more de facto. It's sad to see small teams take it as a given for how things are done. I genuinely think it deforms and delays the solutions they're trying to make for their customers.
    - MattPalmer1086 4y ago
      Sadly, this constant push to measure and control all processes and tasks infects everything, not just development. Enterprise software is appalling at imposing workflows on everything in sight, and they always have pretty graphs and reports for management. I feel quite strongly that software should serve humans, rather than the other way around. These tools do not exist to help you get your job done, they make you its servant. Imagine how much more productive we could be if we had tools designed to actually help us. Management could still get nice reports, but some manager might have to knock up a spreadsheet. I can dream...
      - gmfawcett 4y ago
        Please dream out loud. :) What would those tools look like?
        MattPalmer1086 4y ago
        I can think of some qualities those tools would have. Ease of use, focused simplicity. Interactions should be voluntary, not enforced by a workflow system. Usage metrics shouldn't be exposed outside its users, giving them flexibility to use it however makes sense for them.
eesmith 4y ago
The author points to Microsoft as a typical example of corporate programming in the 1990s. Yet Microsoft wasn't using a (pseudo)waterfall development model. Quoting Steve McConnell in "Rapid Development (1996) Page 271: ] In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale. As I've pointed out before, I've read about software development projects at Apple, Be, Commodore, Data General, id, Infocom, Microsoft, VisiCorp and others. None were using (pseudo)waterfall. I therefore agree with bdefore that it seems to have been "far from ubiquitous and mostly limited to government or very large corporations", and that the era of waterfall was a mythical beast.
- MattPalmer1086 4y ago
  I guess it depends where you worked. I certainly don't claim it was ubiquitous, but I personally saw it at a start up and a small software house. Also government, for sure!
  - sgt101 4y ago
    I saw it at a local council (serving ~300k people) & a small gas (as in methane delivery) company as well as at a very large telco and in government/defence. It may not have been ubiquitous but it was definitely everywhere I worked.
    - eesmith 4y ago
      Yes, "Rapid Development" lists a dozen or more approaches, including iterative prototyping and (modified) waterfall, with pros and cons of each one. My issue with the standard Agile story repeated here is the lack of any mention of pre-Agile approaches other than waterfall. Take: "Rather than clearing the way for software developers to build, waterfall gummed up the works with binders of paperwork and endless meetings." Why is there no mention of any other approach? We can easily point to the Macintosh project, which took 5 years (1979 to 1984). Yet, no waterfall there. Or, take a closer look at: "Peter Varhol, a technology industry consultant, estimates that in the early 1990s, the average application took three years to develop, from idea to finished product." (That's shorter than the Macintosh project.) What does that mean? Which industry? What kind of applications? Clearly a lot of "log cabin" PC applications are excluded from that list - just think of all the DB2 and VB applications people wrote in that era. And video games.
swagtricker 4y ago
Yes. This bullshit you describe was real. I remember having managers in 1998 using Microsoft Project and HUGE plotters that were used for nothing but printing out massive Gantt charts. And, of course, having DAILY meeting when we were behind so that our manager could show with great accuracy how behind we were - and complain he needed more people to manage so he could build his fiefdom.
legulere 4y ago
Waterfall also consists of those phases. One core idea of agile is instead of a big design up front to iterate those phases as fast as possible because often the requirements are not clear from the beginning and you have to see if your ideas bring value to the stakeholders. The problem is that not all tasks can be done in a short time and sometimes need more planning. Planning is often neglected in agile environments. In some environments you also know the requirements beforehand (because they stem from the law for instance), agile development does not work there.
- MattPalmer1086 4y ago
  I completely agree. In my early agile training, the instructor stated it was good for developing where requirements were unclear or responding to small feature requests quickly, due to the fast iterative approach with feedback. He also said that agile was not a substitute for planning. I guess those lessons weren't learned by everyone...
- SAI_Peregrinus 4y ago
  Yep, the design phase shouldn't be an exclusive OR between a large-scale design & small-scale designs with iteration. It should be both: plan the large-scale architecture, marking the bits which are unknown, then iteratively design & build to fill out the unknowns & build the rest of the design. It's a recursive process. solve([problems]) 1. Define car(problems). 2. Plan a solution. 3. Implement the solution. 4. Test the solution. 5. Document the results. Add any problems discovered to the list. 6. solve(cdr(problems))

singron 4y ago

It's funny to me that one of the original descriptions of waterfall is actually something we might consider agile: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... It augments the naive waterfall with continual testing and customer feedback among other things that might surprise you.