Comment by choeger | Hacker News Reader

Comment by choeger | Hacker News Reader

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity.

Waterfall doesn't mean not to iterate. It also doesn't mean to not build prototypes or MVPs. It just pushes the risky decisions back to people that are actually paid to make these decisions. Scrum is not just a framework for micromanaging, it also conveniently removes any domain responsibility from management. It's always "the team decides". (Of course, just on paper. Try to decide to do tech debt only for a couple of sprints with your team and see how management reacts.)

Besides, waterfall is just the straw man of scrum zealots. I once proposed a new team structure where frontend and backend wouldn't be mixed because I observed that most stories didn't have an overlap but where rather mostly one or the other. The scrum master was shocked that I wanted to get rid of "cross functional" teams: "What do you want to do instead, waterfall?". For them it was inconceivable that cross functionality was not equivalent to scrum.

> Waterfall doesn't mean not to iterate

I don't want to be pedantic, but waterfall does mean exactly that by definition (or at least it used to). There are plenty of variations, that include prototypes or MVPs or iterations (e.g. V-Model, Spiral model).

> waterfall is just the straw man of scrum zealots

You can't just change the definition of a word, and then call people using the original definition "zealots", see https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

The question is whether any of the "classical" examples for waterfall project managements out there didn't iterate at all. Having iterations is not incompatible with waterfall per se. E.g. you can plan to have 3 prototypes and then one final product beforehand. You can also decide to skip project phases if they are not needed.

When people hear waterfall they think of a pure methodology, when in practise the methodology nearly always will be (and was) sacrificed if the need arises. So as we are discussing a thing we do in practise, we shouldn't discuss it as a theoretical framework in the vacuum of space, but as something that will be (a)bused in reality.

As a film guy I am a big fan of clear up-front planing (you probably know some of the things that go into films, treatments, scripts, story-boards, concept art, ...) A film is very waterfall-y in how it is produced. But good directors maintain their flexibility on set by maintaining a balance in how serious they take the script on set and where other solutions present themselves that are a thousand times better, e.g. because the location/the actors or whatever is more striking than any writer could have imagined etc.

A term has a meaning, and the fact that people don't actually practice it doesn't mean you can just change what it means.

> A film is very waterfall-y in how it is produced. But good directors maintain their flexibility on set by

Right. So they don't stick strictly with waterfall, even though the industry tends to be "waterfall-y".

My understanding is that in some (non-software) industries, waterfall is practiced because you really can't go back and change things. Or maybe you could, but it would mean increased cost and delays to the extent that you might as well have started all over.

There was a time when people thought "software engineering" was really engineering, so you had to follow traditional engineering best practices. eg. Do it right the first time, make plans and stick with them. It just turns out that this doesn't work for software, and as you said, nobody is really stupid enough to do strictly that now.

> waterfall does mean exactly that by definition

Hilariously: https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_...

> but waterfall does mean exactly that by definition

No.

This article The Myth of the 'Waterfall' SDLC gives you the details (archive version since the site seems to be down) - https://archive.is/jbBta

> Waterfall doesn't mean not to iterate

Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop.

But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself.

(Sadly I’ve lost the link to the original paper, but if I find it I’ll update my comment)

> Besides, waterfall is just the straw man of scrum zealots.

The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with. So many corporate implementations of scrum are AINO - agile in name only. Management that doesn’t understand the complexity of software is doomed to oversimplify it.

That said, if you are working iteratively - one feature at a time, with feedback - then whatever you call it, that’s not waterfall.

> But waterfall itself was a straw man

I disagree. I've been in many projects which looked exactly like the stereotypical waterfall, with the expected results (delays, death marches).

Originally in the W. Royce article from the 70s it was a strawman put up by Royce. He then went on to define much more reasonable iterative model.

Unfortunately the strawman was what started getting traction.

You misunderstand, the idealised waterfall model was literally presented as a straw man.

The horror is that it got picked up as a legitimate SDLC. Hence your exposure to it.

It’s almost like they saw the pictures and didn’t read the words.

Yes, the person that invented the name couldn't possibly imagine anybody was stupid enough to practice that thing he described.

At the same time, that process he described was the standard procedure for government and any large corporation contracts.

> The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with

I worked as an external employee in an environment that had a very functional scrum implementation. You had groomings, plannings, dailys, retrospectives. Every task was defined, estimated, time on them tracked to get better in estimating. You had scrum masters, capacity plannings. On the surface, it was all very functional and productive.

But the reality is, business analysts and product managers who had little knowledge of how the system works were in charge of talking to clients, writing specifications, getting them approved and ready for development, and very little possibility to iterate if there was a problem in the definition.

It was very efficient at building a bad product. :D

Yes, exactly this.

I saw a quote recently from Erik Dietrich that said, "A lot of people mistake activity for productivity” and that describes every scrum implementation I’ve ever seen.

It’s a cargo cult, no doubt in my mind.

This is it, I distinctly recall a reading a paper defining Waterfall as a thought exercise, with the author coming back years later to clarify that there can never be such a thing in software development. The Wikipedia article for "Waterfall model" mentions something like that as well. As an old teacher used to say, "There's no such thing as a Waterfall model, it was your parents all along. All software development is iterative."

Winston Royce actually did have an iterative process as part of Waterfall, it was in his final model, and the diagram was on the next page of the document that most people fail to recognise.

https://upload.wikimedia.org/wikipedia/commons/d/de/1970_Roy...

My recollection from the paper is that he presented what’s typically discussed as waterfall at the start of the paper, and from there developed the iterative process.

Neither process was explicitly called “waterwall” - and the former is what I was taught at software engineering school.

Royce's model wasn't Waterfall. Waterfall is the model he started with, knocked, and then improved on. Idiots in DoD (and from there industry) mistook his first figure as the target, and not the thing to avoid. They codified it in a standard and it has been the cause of much government and government contractor waste ever since.

Reply on news.ycombinator.com