Hacker News Reader

Comment by Stormbringer | Hacker News Reader

Agilistas like to pretend that if you're doing waterfall you can't ever go back to the previous step.

Whereas in practice, if you find something wrong or confusing with the specification, you just hunt down the business analysts and ask them what drugs they were on when they pooped out the spec. And then after walking them through their mistake, you get a new and better spec.

If you do it often enough, they will start to catch on and actually do their job better. Don't think of that as a poke at BA's either, everybody puts more effort in if they know that someone gives a crap about what they do. They may not like it at first, but you're actually empowering them.

View on HN

"Agilistas like to pretend that if you're doing waterfall you can't ever go back to the previous step."

The Agilistas are correct.

The reason for this is that Waterfall was constructed deliberately as a strawman. The very point of constructing Waterfall was to draw a distinction between the process as it was being presented to the VP, or in this case as it is presented to the customer, and the fact that in practice it doesn't work at all and therefore it could not have been what actually happened. Therefore, given that it isn't a possible process anyhow, we should embrace an iterative approach, because ultimately there's no alternative. We should face up to the truth and thereby learn to take proper advantage of it, instead of sneaking it in the back door, hiding it in shame, and deliberately doing stupid things that can't work because management thinks it makes them happy. And in this case, there's no possible way that that is an accurate description of what happens in any significant project that company undertakes.

If you don't understand that Waterfall is not and never was a "real" methodology and don't grasp the history, which it seems still almost nobody does, then you don't really get what's going on. And attempting to rehabilitate Waterfall into a real or viable methodology is metacontrarianism [1] run amok. There's no point in performing CPR on a scarecrow.

[1]: http://lesswrong.com/lw/2pv/intellectual_hipsters_and_metaco...

I thought waterfall was a strawman too, until I read The Checklist Manifesto and started learning more about other industries.

For example, large-scale construction projects like skyscrapers are run by gantt charts and committees, which sounds unbelievable and like a disaster waiting to happen. It's like the opposite of every startup I've worked at in the last 4 years. Except it actually works and they keep the everything running smoothly through:

* (at the top level) real time adjustments to huge room-filling charts that shown all the dependencies.

* (at the grunt level in the trenches) an abundant use of checklists to keep work mistake-free and to avoid groups stepping on each other.

* (at all levels) constant and real time communication. Lots of it.

So yeah, I think it's hard to write off waterfall as both ineffective and non-existent if a large industry uses it to such a degree.

Large-scale construction projects are also notorious for delays and cost overruns, so I wouldn't make too much of that.

Even granting your point, though, that doesn't tell us much about software. Nobody expects to start a building as a small house and work it up to something the size of the Pentagon. You can't automatically replace every screw in a building in minutes. Buildings aren't made out of words, and they don't have requirements that change continuously. Buildings aren't expected to respond quickly to competitor's new amenities. The construction of buildings is not 100% automatable with modern technology. So I wouldn't be too hasty in suggesting that the Waterfall approach is made more plausible by a similar-sounding process being used in an entirely different industry.

And honestly, real buildings aren't even much like what you're imagining. Stewart Brand's book "How Buildings Learn" examines actual buildings and how they adapt and change in ways very different than what people with GANTT charts think should happen.

Waterfall has no such history in the software domain. Analogizing software to construction has a long and worthless history, and it has failed to produce one actionable insight that I'm aware of. (It has produced some really dangerous pronouncements about how software engineering should be done, of the kind that you can crash and wreck a company on, though, so there's that.)

The problem is that construction has a completely, radically different cost model than software. If they could possible throw up one building today, tweak it, and throw up another tomorrow, they'd go iterative too. Instead, they have horrifying implementation costs that have no analogy to software; if Waterfall "works" for them it is only because they have no other choices. That's hardly a ringing endorsement, as wpietri observes.

Reply on news.ycombinator.com