5 ms·

> I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified O

> I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common.

convolvatron 2y ago
I have certainly seen projects that started by planning everything out. High level designs, milestones, integration dates. Giant GANNT charts. But by the second quarter everyone was pretty much just redrawing the whole map, getting what they could running as early as possible and throwing things off the bus.
- Supermancho 2y ago
  I still see it today, in various projects.
jerf 2y ago
If you consider this not as a binary choice, but "waterfall" on one end meaning that the whole design process has basically no feedback, and "agile manifesto agile" (not scrum or any other calcification of the process, but the true chaotic "just depend on your engineers to be smart" process), it's probably true there has never been a "true", all-the-way-to-one-end Waterfall design that went for multiple years, because such a thing is essentially impossible. It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan. I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation. And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
- whatnotests2 2y ago
  > And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around. You captured so much in this one sentence, especially the end, about how waterfall failed the developer, rather than the developer having failed waterfall. This script-flip works on many other systematized orthodoxies, I suspect.
- JohnFen 2y ago
  > I don't consider it a "strawman" so much as a "simplification" I consider it a straw man because, as the agile crowd describes it, there appears to be no such thing as "waterfall". Perhaps that is the result of comical oversimplification rather than a conscious attempt at deception (I believe this is the case), but it still results in standing up a straw man so it can be knocked down.
  - jerf 2y ago
    If a process is 98% waterfall and management blames developers for the 2% and considers it a problem to be solved rather than something to be harnessed, it's close enough to waterfall for all practical purposes. I don't believe there's a sudden transition in the cost/benefits for waterfall at 100%, in either direction. (Just as I don't believe it for Scrum.) The criticisms will apply.
    - JohnFen 2y ago
      > If a process is 98% waterfall I just haven't seen that happen. I'm sure there are exceptions where it has, but I think those have always been rare.
- 2y ago
Swizec 2y ago
> On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall. Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement. You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.
- whatnotests2 2y ago
  Ah yes, the Agile Waterfall method. Lol
- convolvatron 2y ago
  This entire discussion or dichotomy is just a massive and sad misdirection. Its explicitly cargo-culting. In what other world do we spend half of our time talking about and conforming to various 'methodologies'. If we just find the right sprint cadence. If we just do retros better. Maybe some kanban-scrum hybrid. If we just _reallly_ limit standups to 15 minutes. If we clap three times at the end instead of two - then perhaps we will be able to deliver software. There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.
HeyLaughingBoy 2y ago
Neither have I. Most of my software career has been spent in medical device development: a tightly regulated industry, and waterfall is just a concept. Sure, you do requirements elicitation, review and documentation, and then architectural design, followed by detailed design & coding, etc. But it's never a linear process end-to-end. There's always feedback. There's always something you didn't account for showing up and requiring a change to an earlier part of the process. Waterfall can, and does work, but only on fairly small projects that can be completely defined correctly the first time around. And like everything else, it's easier if you've done that kind of project before.
- mrmlz 2y ago
  Waterfall has feedback in it. You got to zoom in on the development V-charts to see it ;)

convolvatron 2y ago

I have certainly seen projects that started by planning everything out. High level designs, milestones, integration dates. Giant GANNT charts. But by the second quarter everyone was pretty much just redrawing the whole map, getting what they could running as early as possible and throwing things off the bus.

Supermancho 2y ago
I still see it today, in various projects.

jerf 2y ago

If you consider this not as a binary choice, but "waterfall" on one end meaning that the whole design process has basically no feedback, and "agile manifesto agile" (not scrum or any other calcification of the process, but the true chaotic "just depend on your engineers to be smart" process), it's probably true there has never been a "true", all-the-way-to-one-end Waterfall design that went for multiple years, because such a thing is essentially impossible. It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan. I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation. And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.

whatnotests2 2y ago
> And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around. You captured so much in this one sentence, especially the end, about how waterfall failed the developer, rather than the developer having failed waterfall. This script-flip works on many other systematized orthodoxies, I suspect.
JohnFen 2y ago
> I don't consider it a "strawman" so much as a "simplification" I consider it a straw man because, as the agile crowd describes it, there appears to be no such thing as "waterfall". Perhaps that is the result of comical oversimplification rather than a conscious attempt at deception (I believe this is the case), but it still results in standing up a straw man so it can be knocked down.
- jerf 2y ago
  If a process is 98% waterfall and management blames developers for the 2% and considers it a problem to be solved rather than something to be harnessed, it's close enough to waterfall for all practical purposes. I don't believe there's a sudden transition in the cost/benefits for waterfall at 100%, in either direction. (Just as I don't believe it for Scrum.) The criticisms will apply.
  - JohnFen 2y ago
    > If a process is 98% waterfall I just haven't seen that happen. I'm sure there are exceptions where it has, but I think those have always been rare.
2y ago

Swizec 2y ago

> On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall. Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement. You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.

whatnotests2 2y ago
Ah yes, the Agile Waterfall method. Lol
convolvatron 2y ago
This entire discussion or dichotomy is just a massive and sad misdirection. Its explicitly cargo-culting. In what other world do we spend half of our time talking about and conforming to various 'methodologies'. If we just find the right sprint cadence. If we just do retros better. Maybe some kanban-scrum hybrid. If we just _reallly_ limit standups to 15 minutes. If we clap three times at the end instead of two - then perhaps we will be able to deliver software. There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.

HeyLaughingBoy 2y ago

Neither have I. Most of my software career has been spent in medical device development: a tightly regulated industry, and waterfall is just a concept. Sure, you do requirements elicitation, review and documentation, and then architectural design, followed by detailed design & coding, etc. But it's never a linear process end-to-end. There's always feedback. There's always something you didn't account for showing up and requiring a change to an earlier part of the process. Waterfall can, and does work, but only on fairly small projects that can be completely defined correctly the first time around. And like everything else, it's easier if you've done that kind of project before.

mrmlz 2y ago
Waterfall has feedback in it. You got to zoom in on the development V-charts to see it ;)