7 ms·

I get that waterfall has a bad reputation, but complex, heavily regulated systems are where waterfall projects shine.

Jtsummers 5y ago
That’s been my world. And no, it doesn’t shine. It’s the worst way to manage a complex project that anyone has conceived of short of anarchic project management with no plans and no deliberate coordination. Waterfall is a great way to fuck up a complex system. It is unresponsive to change. The smallest ambiguity will result in the undesirable outcome of building the wrong thing. The only good thing about Waterfall is that contractors can make bank on the rework, but their customers will be screwed every time.
- greesil 5y ago
  So it's better than anarchy? Admittedly it's a low bar to clear, but what would you propose as better?
  - feoren 5y ago
    A small team of smart people all working together with a shared goal, a clear vision, flexible roles, open communication with subject-matter experts, and a manager who acts as a shield against external forces (obsessive changes, design by committee) and as a provisioner of resources to the team?
    - mmarq 5y ago
      Amen
  - cjfd 5y ago
    Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how it should be in theory but not in practice. Agile in theory is actually a very good development process. Agile in practice tends to be a bit worse. Waterfall always is the hell. My boyfriend is at the moment doing waterfall development. He hates it. So much useless paperwork.
    - aaaaaaaaaaab 5y ago
      Yeah, that’s fine for developing the new landing page for the company website. Not so much for developing mission critical systems.
      - cjfd 5y ago
        I disagree. Among the things that I listed was TDD. If one practices that consistently one can create highly reliable software. In fact one might argue that using TDD for the new landing page for the company website might be overkill. Maybe you do need a bit more planning for your 'mission critical system' in order to perhaps attain performance goals. However, I will tell you here and now that if you just do TDD for your mission critical system and you do it well you will already be better than most programming going on for so-called missions critical systems in many, many places.
        iratewizard 5y ago
        TDD is cargo cult.
        cjfd 5y ago
        It really is not. TDD is for highly competent programmers.
        aaaaaaaaaaab 5y ago
        Lol, not really: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
        dragonwriter 5y ago
        > TDD is cargo cult. No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
  - iso1631 5y ago
    > So it's better than anarchy? Sometimes, but in my experience anarchy (which adds some business value, in a non specific way) is often better than waterfall (which adds none and actually hinders by preventing small quick schemes that add value now for the promise of value in years to come)
  - Jtsummers 5y ago
    Anything that has feedback loops and responds to differences between reality and the plan by favoring reality. I have watched too many Waterfall proponents lead projects to failure because they were too stupid to acknowledge that reality had diverged from expectations. For software systems, specifically, also anything that encourages early integration. Integrate early, integrate often. A failure to do so means that you've broken your feedback loops or extended them to an arbitrary time in the future so that they have little to no value. You cannot properly verify and validate a system without integrating the major subsystems. Independent of most of the named processes and the technical discipline, V&V. Verification and validation are critical, ongoing activities that must be part of your work. This largely pushes towards automated testing, formal specs where applicable, and customer collaboration (to get validation of the system at critical junctures). Waterfall doesn't do any of those things or isolates them (like V&V). It only works on large scale systems if reality matches expectations, which is rare. My preference is to look towards Lean Software, most of the Agile methods, and the classical methods like Iterative & Incremental and Evolutionary (which were agile before Agile). V-Model is Waterfall-ish but integrates feedback into the system and makes V&V an ongoing activity. I prefer it paired with I&I or Evolutionary for critical systems (my primary domain).
shantnutiwari 5y ago
yeah, waterfall has its uses. It's not the evil puppy killer everyone makes it out to be
MattGaiser 5y ago
I can see why waterfall doesn't work, but as a dev, it is pretty nice to have a detailed spec. Covers my ass.
- jrochkind1 5y ago
  Waterfall is indeed the domain of valuing covering your ass over producing business value.
  - deleted 5y ago
    [deleted]
- tomosaki 5y ago
  I think more teams need to learn to do better documentation and specs with Agile. So many teams think that it’s just not needed.
oxfordmale 5y ago
The problem is that waterfall is a myth propagated by the Agile evangelists. Development waterfalls were not frozen and rigid as claimed by Agile advocates, but we're in fact fluid allowing certain steps to start before others were finished.
- tonyedgecombe 5y ago
  Everywhere I've seen it management had the expectation that the requirements were frozen, that the project would be on time and costs were fixed.
  - oxfordmale 5y ago
    This gives a good historical overview: http://www.bawiki.com/wiki/Waterfall.html http://www.bawiki.com/wiki/Waterfall.html Wikipedia gives a shorter version: In fact Royce, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn, demonstrated that while the development of large software systems required a more thorough approach, there was inherent risk in a single-pass sequential approach. He proposed an iterative approach and advocated that projects should pass through this at least twice.

That’s been my world. And no, it doesn’t shine. It’s the worst way to manage a complex project that anyone has conceived of short of anarchic project management with no plans and no deliberate coordination. Waterfall is a great way to fuck up a complex system. It is unresponsive to change. The smallest ambiguity will result in the undesirable outcome of building the wrong thing. The only good thing about Waterfall is that contractors can make bank on the rework, but their customers will be screwed every time.

greesil 5y ago
So it's better than anarchy? Admittedly it's a low bar to clear, but what would you propose as better?
- feoren 5y ago
  A small team of smart people all working together with a shared goal, a clear vision, flexible roles, open communication with subject-matter experts, and a manager who acts as a shield against external forces (obsessive changes, design by committee) and as a provisioner of resources to the team?
  - mmarq 5y ago
    Amen
- cjfd 5y ago
  Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how it should be in theory but not in practice. Agile in theory is actually a very good development process. Agile in practice tends to be a bit worse. Waterfall always is the hell. My boyfriend is at the moment doing waterfall development. He hates it. So much useless paperwork.
  - aaaaaaaaaaab 5y ago
    Yeah, that’s fine for developing the new landing page for the company website. Not so much for developing mission critical systems.
    - cjfd 5y ago
      I disagree. Among the things that I listed was TDD. If one practices that consistently one can create highly reliable software. In fact one might argue that using TDD for the new landing page for the company website might be overkill. Maybe you do need a bit more planning for your 'mission critical system' in order to perhaps attain performance goals. However, I will tell you here and now that if you just do TDD for your mission critical system and you do it well you will already be better than most programming going on for so-called missions critical systems in many, many places.
      - iratewizard 5y ago
        TDD is cargo cult.
        cjfd 5y ago
        It really is not. TDD is for highly competent programmers.
        aaaaaaaaaaab 5y ago
        Lol, not really: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
        dragonwriter 5y ago
        > TDD is cargo cult. No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
- iso1631 5y ago
  > So it's better than anarchy? Sometimes, but in my experience anarchy (which adds some business value, in a non specific way) is often better than waterfall (which adds none and actually hinders by preventing small quick schemes that add value now for the promise of value in years to come)
- Jtsummers 5y ago
  Anything that has feedback loops and responds to differences between reality and the plan by favoring reality. I have watched too many Waterfall proponents lead projects to failure because they were too stupid to acknowledge that reality had diverged from expectations. For software systems, specifically, also anything that encourages early integration. Integrate early, integrate often. A failure to do so means that you've broken your feedback loops or extended them to an arbitrary time in the future so that they have little to no value. You cannot properly verify and validate a system without integrating the major subsystems. Independent of most of the named processes and the technical discipline, V&V. Verification and validation are critical, ongoing activities that must be part of your work. This largely pushes towards automated testing, formal specs where applicable, and customer collaboration (to get validation of the system at critical junctures). Waterfall doesn't do any of those things or isolates them (like V&V). It only works on large scale systems if reality matches expectations, which is rare. My preference is to look towards Lean Software, most of the Agile methods, and the classical methods like Iterative & Incremental and Evolutionary (which were agile before Agile). V-Model is Waterfall-ish but integrates feedback into the system and makes V&V an ongoing activity. I prefer it paired with I&I or Evolutionary for critical systems (my primary domain).

shantnutiwari 5y ago

yeah, waterfall has its uses. It's not the evil puppy killer everyone makes it out to be

MattGaiser 5y ago

I can see why waterfall doesn't work, but as a dev, it is pretty nice to have a detailed spec. Covers my ass.

jrochkind1 5y ago
Waterfall is indeed the domain of valuing covering your ass over producing business value.
- deleted 5y ago
  [deleted]
tomosaki 5y ago
I think more teams need to learn to do better documentation and specs with Agile. So many teams think that it’s just not needed.

oxfordmale 5y ago

The problem is that waterfall is a myth propagated by the Agile evangelists. Development waterfalls were not frozen and rigid as claimed by Agile advocates, but we're in fact fluid allowing certain steps to start before others were finished.

tonyedgecombe 5y ago
Everywhere I've seen it management had the expectation that the requirements were frozen, that the project would be on time and costs were fixed.
- oxfordmale 5y ago
  This gives a good historical overview: http://www.bawiki.com/wiki/Waterfall.html http://www.bawiki.com/wiki/Waterfall.html Wikipedia gives a shorter version: In fact Royce, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn, demonstrated that while the development of large software systems required a more thorough approach, there was inherent risk in a single-pass sequential approach. He proposed an iterative approach and advocated that projects should pass through this at least twice.