Re: OpEd: Programming is not Team Sports

[BrowserUk]

I think that too many developers derisively dismiss The Waterfall Model as being somehow oldy-moldy and out of fashion.

The Waterfall Model doesn't work. I'm not citing (just) my own opinion here, but rather that of the man, Dr. Winston W. Royce, that first described the waterfall model.

Yep! The guy that 'invented' the Waterfall Model, said it didn't work. Indeed, when he first described it in his 1970 paper:"Managing The Development Of Large Software Systems", he did so explicitly to show why it didn't work, and what needed to be done to correct the method's inherent, designed-in, causes of failure.

See this For a potted history of how the mis-citing of the Royce paper, lead to it getting accidentally adopted by the US military in the early 70's; and thence forth by many other organisations who blindly copied them; before being universally abandoned by all of them in the mid to late 80's because it failed so badly, so often.

“Those who fail to learn from history are doomed to repeat it.” -- Sir Winston Churchill

[jdporter]

Royce, in that paper, clearly isn't dismissing the waterfall model entirely; rather, he says it needs to be elaborated -- to be made more complex -- in order to work. Look at the last page, Figure 10. This illustrates the model he says works, and it's clearly a form of waterfall. So if one is going to cite the "wisdom" of Royce, one has to admit that he thought the 'waterfall', as it is understood and practiced today, does not inherently lead to failure.

"I'm willing to let Churchill have the credit." -- George Santayana

[BrowserUk]

Look at the last page, Figure 10. This illustrates the model he says works, and it's clearly a form of waterfall.

Sorry, but you are wrong.

The bit of fig.10 that looks like the waterfall model -- the bit to the right of the dashed line -- is simply a reiteration for contrast of fig.4, of which Royce says (in the text above fig.4):

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

The bit of fig.10 to the left of the dashed line is his alternative designed to correct the flaws in the waterfall model, which with its feedback loops and iterative processes is clearly the antithesis of the (no going back; never throw anything away) waterfall model.

Instant analysis doesn't cut it here.

[jdporter]

The bit of fig.10 to the left of the dashed line ... is clearly the antithesis of the ... waterfall model.

I disagree with you. But I won't say "you are wrong", because there is no objective reality here.

On the other hand, you were wrong about the origin of the quote. :-)