Don’t go chasing waterfalls…

Ah, the (in)famous Winston Royce paper where he describes the standard linear approach to project delivery. This is either the greatest gift to project management ever, or the exact reason why we should all go Agile.

Well, not quite. It really depends on who you ask…

So let’s start with exhibit A, the paper itself: Managing the Development of Large Software Systems by Dr. Winston W. Rovce.

I pulled a PDF copy from here and a couple things stand out.

Figure 2. is where we get the full Waterfall shown (see below):

Implementation steps to develop a large computer program for delivery to a customer.

Implementation steps to develop a large computer program for delivery to a customer.

The first line after this figure is:

I believe in this concept, but the implementation described above is risky and invites failure.

And why is it so risky?

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 100-percent overrun in schedule and/or costs.

Royce then states that “believe the illustrated approach to be fundamentally sound” and goes on to describe how to reduce this overrun risk.

The key for Royce is to add a “preliminary program design phase” before the specification has been created. He accepts that this means the “program designer is forced to design in the relative vacuum of initial software requirements” and that this would be sub-optimal compared to writing with the full specification, but by doing so “the program designer assures that the software will not fail because of storage, timing, and data flux reason.

How very Agile…

So the very paper that many used to justify Waterfall states clearly the risk and how it should be overcome by coding first.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s