Comment by ternaryoperator | Hacker News Reader

Comment by ternaryoperator | Hacker News Reader

Parent Full thread

ternaryoperator

"Pure waterfall as it's depitected by Agile consultants was never a thing."

This is correct.

The first paper to describe a stepwise model was by Royce in 1970 [1]. The model he is describing is hypothetical and does not use the term Waterfall.

The first use of the word "waterfall" (including the quotation marks) is from 1976 [2] and specifically refers to [1], the hypothetical model. In [2], the writers specifically state that "so few" projects fit this scheme.

If you were programming in the 80s and early 90s, you would know that no one in programming ever referred to a "waterfall" model.

Even Kent Beck's seminal book on XP, written in 2000, describes many failures of software development in those days, but he does not once use the word Waterfall.

So, in summary: the paper that supposedly describes it describes a hypothetical system; the paper that first uses the term mentions how little the model is used; the term wasn't used by people during the era it was supposedly most popular; and the folks who initiated the new generation of software dev don't refer to the model.

I think it's safe to say that it was not a thing. Or, to be more accurate, if it was a thing, it was never the thing it became until the Agile consultants used is as a strawman.

[1] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

[2] https://goo.gl/eYLBN7

The term "Waterfall" was not applied.

but it absolutely was very common to use the process that it implies.

many man-years of gathering requirements, building lists of features, interrogating stakeholders.

people knew they would never get a second chance to get what they wanted, so they would throw every feature in that they could think of.

Then the developers would build it. more man years building. mostly they tested as they went along, but....different features and areas of the app were often build in isolation, so the most you could say was that you had tested what you had built.

the stakeholders were consulted with screenshots, and sometimes the app, but the Big Fear was new features and additional requirements (which would cause massive contractual headaches) so any contact was VERY carefully controlled.

Also it was assumed every project was massively valuable IP, so detailed designs and features were held very close to the chest..again, any contact was VERY carefully controlled.

Eventually, after months or years of effort the various parts of the app would be "merged". omg the cluster fuck that would occur, the compromises, and arguments, the agonizing...

..then more testing..

Once that was completed the brilliant new creation would be seriously unveiled to the users to cheers and relief.

Finally, the contractual battles would begin as the paying company realised they had asked for entirely the wrong thing, and the development company tried desperately to cover their ass and make a profit.

The single biggest problem that Agile fixes isn't the testing, its the disconnect between what the client wanted and what the developers actually deliver.

I was there in the mid-nineties, and it was absolutely a thing in enterprise style IT.

There were also several books on the matter, and also revised waterfall models. The very term was not always used early on (though around the nineties it did), but the schemes were the same.

Lots of public projects, including some I've been involved, were designed and managed in such a way.

There were no changing requirements until the things were delivered, which could take 1-2 full years. The design phase resulted in monstrous 400 or 800-page documents covering every aspect, and to apply for such a software tender you needed to write those in excruciating detail (I did that too for several projects).

The waterfall model, with the name and all, was also taught at our university (early/mid nineties). XP wasn't even mentioned back then at our level, though we discovered it on our own, reading Fowler, Beck et al in the late nineties.

There's some tinfoil conspiracy theory thrown around that Waterfall was never a thing etc, and it was just used to push Agile etc. I wonder what its adherents did in the 80s and 90s, but surely not programming in large enterprise/public/military etc software projects.

(That Waterfall cannot work is another thing altogether -- nobody did it 100%, as nobody does Agile 100% today).

People would refer to "The Software Development Life Cycle", which was by all means a waterfall-esque process (look it up on Google, you'll see the classic waterfall diagram used for it). The word itsself may have been coined as something to compare Agile against, but the process itself existed, and existed long after Agile had "won" in more traditional companies.

I ran projects that ran through a VERY traditional waterfall process as recently as 2010.

Saying that the term was never used isn't really refuting the point. It doesn't matter whether you coded back in those days. Anyone who looks at (or used) the software being produced back then can see that continuous software delivery wasn't really the norm, probably due at least in part to technical limitations. I'm thinking about your average Microsoft product, but there are plenty of examples even today of poorly-designed waterfall projects (e.g., healthcare.gov for Obamacare).

You're wrong. Look at the responses you're getting, many of us were there in the 90's and if you think waterfall wasn't the dominant method of developing then you just don't know what was going on back then. It doesn't matter if they called it "waterfall" or not, it matters that it's simply what they were doing. Massive requirements gathering and spec writing with development being considered like construction of a blueprint at the end of a months/years long cycle. That's how development was done before agile came around.

Waterfall still isn't dead and will never die because it's how people think by default, plan it all out, then build it. That's how buildings are made and thus it becomes the default methodology of all new managers who don't know what they're doing.

Parent just took a "conspiracy theory" thing that's popular around Waterfall and run off with it.

Reply on news.ycombinator.com