Water Fall Myths

[moved from WaterFall]

There can be only one!

The failure of WaterFall lies in a false attempt to eliminate duplicate effort. You can't do it right, and instead of documenting it and introducing a best-effort for the current circumstances, you try and move the ground under your feet.

WaterFall done right: spend some time thinking about what you're doing, analyze and design and implement for testing, get it some feedback, and with the new requirements do it over again.

None of the waterfall phases should take too long. If you're taking too long you're probably trying to swim upstream against the waterfall, doing analysis and design at implementation time, or something of that character.

The first time over the waterfall, you're going to have a "substandard" product. Hopefully, you'll have the most important features in place, but that's about it. But just implementing it, and having something to play with will expose important requirements and allow you to do it better.

The biggest mistake people make, with waterfall, is thinking that there can be only one waterfall. But waterfalls aren't about standing still.

Yes they are - or they're about doing things once. The waterfall metaphor, as far as I understand it, is that you go down the waterfall in stages (requirements, design, implementation, test, release). You can't swim up the waterfall. If you're repeatedly going down the waterfall, that's something different.

Get the thing out the door, and then do it again. Code re-use is not just a pot of gold at the end of the rainbow, it is (or should be) a reflection of the part of the design you got right last time that helps you focus on the real problems.

In which case, waterfall encompasses just about any methodology, and is therefore fairly useless as a part of the taxonomy of methodologies.

The 'repeated waterfall' is usually referred to as the SpiralModel. -- TimLesher

CategoryApplicationDevelopment