3 ms·

"waterfall" is just a pejorative term for the kind of planning represented by a Gantt chart, which kinda looks like a waterfall. This kind of planning is _nece

"waterfall" is just a pejorative term for the kind of planning represented by a Gantt chart, which kinda looks like a waterfall. This kind of planning is _necessary_ for traditional engineering projects where certain steps of the process can take months or years and requires scheduling of many resources. Purely software projects usually don't need that because if your tools are good you can ship a completely new version in minutes to hours instead of months to years. You also get very easy do-overs if there are mistakes which you don't get if you're building a bridge or a factory.

deleted 2y ago
[deleted]
janpieterz 2y ago
Waterfall in software development was different than a Gantt chart based "project that was managed" like the construction of a bridge (an example close to my house). They added new requirements to this bridge (like they wanted the surrounding grounds to be maintained nicely, so added irrigation and gardening etc). But no new requirements were added to the foundational "here's a bridge and it needs to cross this stream from this point to that point" (high level). Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. That's where the anti-Gantt and "bad waterfall" comes from, the reality is the software world as a whole moves way quicker and requirements are way more malleable, subjective than building a bridge.
- colechristensen 2y ago
  >Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. Exactly this same thing also happens in non-software "waterfall" projects as well. Mid-project fundamental requirements changes which result in having to re-engineer large parts of the project. This is one of the reasons military acquisitions are so expensive, there's a huge problem with requirements changes.
  - com 2y ago
    And thus us why large-scale construction companies can bid so low, because most of their revenue and profit come from the inevitable scope and requirements changes later in the projects.
  - janpieterz 2y ago
    Perhaps to some degree, but I've never seen a skyscraper that was almost done being torn down to be re-architected and rebuilt.
ethbr1 2y ago
The phrasing I once heard (source sadly lost to my memory) "If the physical properties of concrete changed every 6 months, then structural engineering practices would look very different." But that's the world most software is developed and lives in.
- kabdib 2y ago
  "This avionics firmware is absolutely terrible." "Well, last week it was driving a bus."
  - erik_seaberg 2y ago
    I'm reminded of a build break in Google web search because of a dependency on the self-driving car project. And that's how Bazel rules were given visibility lists.
weinzierl 2y ago
That you can ship quickly is not really relevant though. Case in point is that you most often cannot change the architecture midways without permanent damage. That's why many software projects architecture looks like a building where the architect completely changed their mind after every floor, why everyone complains about technical debt and projects are often thrown away after a couuple of years and rewritten from scratch. I'm not saying agile has no place, just that many projects would benefit from a little bit more foresight. Also, I think successful agile projects are often those where the long term planning is there, even if it is not obvious or talked about a lot.
- colechristensen 2y ago
  >I'm not saying agile has no place, just that many projects would benefit from a little bit more foresight. There is really a spectrum of choices for how much you plan and tradeoffs with each level. Success is finding the right balance for you, your team, and your product.
supportengineer 2y ago
> "you can ship a completely new version in minutes to hours" Not all that long ago, software was distributed on physical media such as floppy discs and CD-ROMS.
marcosdumay 2y ago
> This kind of planning is _necessary_ for traditional engineering projects People keep repeating that, without any empirical evidence at all. If it were only software developers justifying a body of knowledge, it would be ok, but all kinds of people keep repeating that. Yet, that kind of planning predictably fails every single time in every single engineering practice. I can guarantee you, if an engineer designs the structure of a bridge, send it to a crew to construct, and go away to only test after it's done, the bridge will fall down before it's even built.
- bluGill 2y ago
  the fault is not allowing time to test and fix in the right places not in wanting a schedule.
  - marcosdumay 2y ago
    The schedule also does never work anyway. Passing a design down and going away doesn't work. Scheduling tasks before you star them doesn't work. Testing only at the end doesn't work. The one thing civil engineering has that resembles PMBoK is designing things beforehand. And only civil engineering does that, only because they can't prototype.
    - colechristensen 2y ago
      The benefit of a Gantt chart isn't meeting deadlines, it is organizing work. You have all of the steps and what each of them depends on and a timeline. If something slips you know how to update your estimates for everything downstream. If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively.
      - marcosdumay 2y ago
        > If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively Hum... Have you used them that way? And have you needed a project design to actually discover risks and estimate that you need to act on them? Or better, have you found any unexpected risk on a project design, and seen it materialize on practice? > If something slips you know how to update your estimates for everything downstream. And then your renewed estimates will be wrong again. No idea if more or less wrong than before your revision though. It can go either way.

deleted 2y ago

[deleted]

janpieterz 2y ago

Waterfall in software development was different than a Gantt chart based "project that was managed" like the construction of a bridge (an example close to my house). They added new requirements to this bridge (like they wanted the surrounding grounds to be maintained nicely, so added irrigation and gardening etc). But no new requirements were added to the foundational "here's a bridge and it needs to cross this stream from this point to that point" (high level). Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. That's where the anti-Gantt and "bad waterfall" comes from, the reality is the software world as a whole moves way quicker and requirements are way more malleable, subjective than building a bridge.

colechristensen 2y ago
>Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. Exactly this same thing also happens in non-software "waterfall" projects as well. Mid-project fundamental requirements changes which result in having to re-engineer large parts of the project. This is one of the reasons military acquisitions are so expensive, there's a huge problem with requirements changes.
- com 2y ago
  And thus us why large-scale construction companies can bid so low, because most of their revenue and profit come from the inevitable scope and requirements changes later in the projects.
- janpieterz 2y ago
  Perhaps to some degree, but I've never seen a skyscraper that was almost done being torn down to be re-architected and rebuilt.

ethbr1 2y ago

The phrasing I once heard (source sadly lost to my memory) "If the physical properties of concrete changed every 6 months, then structural engineering practices would look very different." But that's the world most software is developed and lives in.

kabdib 2y ago
"This avionics firmware is absolutely terrible." "Well, last week it was driving a bus."
- erik_seaberg 2y ago
  I'm reminded of a build break in Google web search because of a dependency on the self-driving car project. And that's how Bazel rules were given visibility lists.

weinzierl 2y ago

That you can ship quickly is not really relevant though. Case in point is that you most often cannot change the architecture midways without permanent damage. That's why many software projects architecture looks like a building where the architect completely changed their mind after every floor, why everyone complains about technical debt and projects are often thrown away after a couuple of years and rewritten from scratch. I'm not saying agile has no place, just that many projects would benefit from a little bit more foresight. Also, I think successful agile projects are often those where the long term planning is there, even if it is not obvious or talked about a lot.

colechristensen 2y ago
>I'm not saying agile has no place, just that many projects would benefit from a little bit more foresight. There is really a spectrum of choices for how much you plan and tradeoffs with each level. Success is finding the right balance for you, your team, and your product.

supportengineer 2y ago

> "you can ship a completely new version in minutes to hours" Not all that long ago, software was distributed on physical media such as floppy discs and CD-ROMS.

marcosdumay 2y ago

> This kind of planning is _necessary_ for traditional engineering projects People keep repeating that, without any empirical evidence at all. If it were only software developers justifying a body of knowledge, it would be ok, but all kinds of people keep repeating that. Yet, that kind of planning predictably fails every single time in every single engineering practice. I can guarantee you, if an engineer designs the structure of a bridge, send it to a crew to construct, and go away to only test after it's done, the bridge will fall down before it's even built.

bluGill 2y ago
the fault is not allowing time to test and fix in the right places not in wanting a schedule.
- marcosdumay 2y ago
  The schedule also does never work anyway. Passing a design down and going away doesn't work. Scheduling tasks before you star them doesn't work. Testing only at the end doesn't work. The one thing civil engineering has that resembles PMBoK is designing things beforehand. And only civil engineering does that, only because they can't prototype.
  - colechristensen 2y ago
    The benefit of a Gantt chart isn't meeting deadlines, it is organizing work. You have all of the steps and what each of them depends on and a timeline. If something slips you know how to update your estimates for everything downstream. If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively.
    - marcosdumay 2y ago
      > If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively Hum... Have you used them that way? And have you needed a project design to actually discover risks and estimate that you need to act on them? Or better, have you found any unexpected risk on a project design, and seen it materialize on practice? > If something slips you know how to update your estimates for everything downstream. And then your renewed estimates will be wrong again. No idea if more or less wrong than before your revision though. It can go either way.