1. 20

I modified the title to convey the importance to the readers. It was an early paper on managing software projects with all that came with that. The process the author pushes is iterative. However, someone decided to clip out the first, incorrect process with waterfall-like diagram to show to all kinds of business people. Waterfall methodology was born. It wasn’t the technical people, though, who had already invented iterative software in the SAME PAPER! Especially see “dang’s” link to rest of the story.

https://news.ycombinator.com/item?id=10927241

  1.  

  2. 8

    It is one of the running gags of software development.

    1. 8

      There’s a great talk by Glenn Vanderburg called “Real Software Engineering” where he compares software development to other engineering practices. It’s really great and worth watching. He really goes into this document and tries to explain why everybody took the first illustration from the document as “the model” for a software project eventhough they only looked at the pictures.

      I think it’s also mentioned in the HN Thread.

      1. 6

        at a talk he [Larman,he original Waterfall author] said that he tracked down the guy who standardized waterfall for the DoD (in Boston IIRC) and when they met for lunch, the first thing he said to Larman was “I’m so sorry”.

        https://news.ycombinator.com/item?id=10935431

        1. 3

          Yes, you’re right, waterfall the way is described today to promote other methodologies did never exist.

          Even in the old days when you had highly paid consultants of Company A doing the analysis and Company B doing the programming, updates (feedback) to the analysis document created in the previous phase was something usual and expected.

          1. 4

            Yes, you’re right, waterfall the way is described today to promote other methodologies did never exist.

            I was taught The Waterfall Method in high-school (around 2006) and tested on it. It existed, to unfortunate Australian school students :)

            1. 1

              It’s like the UNIX and C were a hoax gag. Except it’s real, done in businesses, mandated in many schools, and surviving the Agile wave through sheer inertia and control-freak managers. Human nature in action…

          2. 2

            I enjoyed Brian Okkens podcast about this: http://pythontesting.net/podcast/waterfall/

            1. 2

              More accurately: the original waterfall paper is waterfall; the “waterfall” scapegoat isn’t.

              1. 2

                That’s an interesting thought but I don’t think it applies. Waterfalls don’t flow back up. The first diagram, waterfall, was an ideal model where everything was perfect. The next have feedback loops reflecting what happens in imperfect, real world. The waterfall scapegoat is what’s in the original paper but misrepresented as realistic and effective. Then scapegoated again by opponents who often act like that was only thing going on in the old days where many teams did iterative forms of development. It was such common sense to professional engineers that they just didn’t waste time to write academic papers along the lines of “Yeah, we screw stuff up periodically that we have to fix. Happens all over the place in projects.”

              2. 2

                Glenn Vanderburg gave a great talk about this at LoneStarRuby 2010

                https://www.youtube.com/watch?v=_EWUeZoyB0k

                1. 0

                  DanG on Hacker News is a cancer.

                  Since OP mentioned him, the fact is relevant.

                  That said, this is absolutely correct. Waterfall was always posed as an anti-pattern. This doesn’t excuse “Agile” garbage– that’s a false dichotomy invented to sell Agile. Software management hasn’t learned a thing. It probably never will, since the trend favors inexperience.

                  Some have also argued that the Gang of Four design patterns were not presented as “how something should be” but “what you will have to deal with in real-world janky code” and that design patterns became “the way it’s done” in Corporate America by accident. It would be something like the Liar’s Poker effect.

                  1. 2

                    “Since OP mentioned him, the fact is relevant.”

                    It’s irrelevant. Keep politics out of it. Dude knows quite a bit about IT history with probably the best submission I saw on the topic in the HN discussions. So, he gets credit for his contribution. Simple as that.

                    “that’s a false dichotomy invented to sell Agile.”

                    Waterfall predates Agile. So, do iterative solutions. The popular competition to Waterfall was Spiral model. Then, the Agile wave hit pretending like it was only thing that ever did iterative development and thorough testing. At least they got some people out of Waterfall, though. I’ll give them that. Between the two, Agile was a less destructive form of bullshit that at least had some benefits. How about that haha.

                    “that the Gang of Four design patterns were not presented as “how something should be” but “what you will have to deal with in real-world janky code” and that design patterns became “the way it’s done” in Corporate America by accident.”

                    I’m still not sure. I just don’t have the experience or large-scale data to know. I mean, I read them seeing benefit out of many with a feeling many might complicate software, too, vs clean, structured programming with a semi-functional style. Many people with lots of experience claims lots of benefit. Then, later people looked critically saying some worked but some were dubious. Management sure ran with it as another checklist or special project thing. I just wonder how much to blame them and how much to blame the patterns themselves as Gang of Four might have known what would happen. It also seems a bit unscientific to push them unless we’ve experimented with numerous solutions to various problems they discussed to check the merits of each in real-world software.

                    I’m still for Cleanroom w/ Haskell (or ML’s), Design-by-Contract, and semi-automated testing. That’s adding proven value to the last methodology that was easy to use with scientific evidence that it worked on diverse projects.