Hacker News Reader

> 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.

It's not really binary or a spectrum. Royce was not taking about what he observed people doing, but how he believed large software projects should be conducted in the future.

In that, he first introduces what has come to be known as Waterfall. While he considered it to be fundamentally sound, he posits that it carries significant risk and then goes on to tell what needs to be added to diminish the risk. Those additions are what oft get called Agile (although not in the Manifesto sense).

You have a point that "simplification" is more in line with the device he was trying to use, but with the intent of leading you into understanding the more complex aspects of his idea. Kind of like that owl drawing meme where you start with two circles and then draw the rest of the owl. There is only one idea present. In other words, "Waterfall" and "Agile" are the exact same thing, just at different stages of communication.

Where others have tried to invent "Waterfall" as it own distinct thing to contrast with "Agile", it would be fair to characterize that as a strawman. If anything all projects are "Agile" at their core, with varying degrees of deviation happening in a multi-dimensional space.

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

If the software industry had the equivalent of "general contractors" who pour the concrete, wire the rebar, dig and fill the holes, install the electrical and duct, laid the bricks, all to within the tolerances specified; AND had architects who knew both the tools available and the domain inside and out, a model mirroring the real estate industry MIGHT BE doable. But there are a lot of differences beyond just the "engineering" aspects (and often times, the head engineer on a project is not the architect).

> 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.

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.

> 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.