Why I Love Waterfall Software Development.

‘Everyone’ knows that ‘Waterfall’ Software Development was heralded in by the seminal 1970 paper “Managing the Development of Large Software Systems“ by Dr. Winston W.Royce

Everyone knows this…except that what he actually invented might just have been Specification Driven Development (we now know this as ATDD) – constrained by the limitations of 1970’s technology, of course.

Isn’t this a Beautiful Waterfall….!

After laying out his basic waterfall in figure 2, Royce says “I believe in this concept but the implementation described above is risky and invites failure”. He goes on to say, that if you leave testing to the end, then you are pretty much guaranteed to have “up to 100-percent overrun in schedule and/or costs” .

Royce’s solution to this testing/specification error, therefore was to add an iterative feedback loop after the first round of prototype/testing:

Not happy with that, though, although he believes the approach is basically sound, Royce says that five additional steps are necessary to make the process work:

1. Program Design Comes First.
2. Document the Design.
3. Do it Twice.
4. Plan, Control, and Monitor Testing.
5. Involve the Customer.

1. Program Design Comes First

Royce was straight off the Apollo Missions – mostly concerned with software designed for spacecraft mission planning, commanding, and post-flight analysis. He lived in a world where the analysis and coding phases ...”are managed with relative ease and have little impact on requirements, design, and testing”. In his world, once you had analyzed your orbit mechanics, spacecraft attitude determination and so forth, then coding involved “a few lines of serial arithmetic code”.

It is the analysis and program design, then, which constitute the emergent unknowns. In 1970, these were best expressed through algorithms, models, and other forms of documentation. The documentation, therefore, WAS the deliverable. He writes “…the documentation IS the specification and IS the design. Until coding begins these three nouns (documentation, specification, design) denote a single thing.”

Royce describes a domain and a time when the analysis of the problem is necessarily constrained by the limitations of the system designed to solve it. ‘Design’ here describes the operational parameters of the system – it defines what is feasible. “By this technique the program designer assures that the software will not fail because of storage, timing, and data flux reasons”.

It is clear from this where Royce had seen projects fail in the past, but the more interesting observation is that the problem analysis and the system design are iterative and, in today’s agile parlance, dare I say, emergent.

2. Document the Design

ATDD is defining system requirements in terms that are directly testable. Royce writes: “The real monetary value of good documentation begins downstream: During the Testing Phase, with good documentation the manager can concentrate personnel on the mistakes in the program. Without good documentation, every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area”

When Royce writes “each and every worker must have an elemental understanding of the system” – is that really that much different from Three Amigos, or Design Studios in today’s precepts?

3. Do it Twice

Build a prototype, get feedback, redesign, and refactor. I’m wondering where I’ve heard that before?

4. Plan, Control, and Monitor Testing

How can we, as agilists, argue with any of this?

1. Tests should be designed and written clearly so they are understandable by non-developers.
2. Code should be reviewed by another person before anything else.
3. Maintain 100% Unit and Functional Test Coverage. “Test every logic path in the computer program at least once with some kind of numerical test”

5. Involve the Customer

This sounds eerily familiar too….Royce writes “For some reason, what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery.”

Nothing New Under the Sun

So it turns out that Waterfall is Agile, Agile is Waterfall. After translating for 1970’s technology, where program design is the riskiest part of the project, and where documentation means testable specifications, what we have here is ATDD….isn’t it??