Systems & Software Talk 

The Waterfall aka Cascade

People flock to Niagara and Victoria Falls. When people mention software development and waterfall in the same discussion, people become agilisticated, (see footnote 1) grab pills to pop, grab counter-culture folk music, and with extreme agility flock to severe weather shelters; shedding crumbs of scrum cemented to beads of forehead sweat during their haste. Davy Devodefectisius sheds much more. His beads of sweat mix with his testosterone from a hormone spike that transpired while he was ogling Candice Compilerati in the project meeting that just came to an abrupt end as people heard the word "Waterfall" and now make haste scrummying to the emergency exits. Drug-sniffing dogs begin to bark uncontrollably to escape their confines and track down the pill-poppers. Cal-Poly seismographs awaken Richter. Why am I blogging this?

The myths and misunderstandings accompanying the term "Waterfall" have a surprisingly simple origin. We will get to that later. When the term "Waterfall" was first coined, there was no baggage. I find it amazing how much baggage it has acquired through the years. The following is a list of some of the baggage.

RELATED HEALTH ISSUES

"Waterfall" has sparked controversy and software development methodology wars. There are and have been victims. The traumatized victims are responsible for a huge increase in medical claims related to Develmethodus Syndrome. This syndrome – DS causes analysis paralysis in the victim, which may lead to truth-about-waterfall shock. That shock should be treated immediately by soothing the victim with the standard suite of Waterfall untruths.

DS manifests itself most often in IT meetings involving software development planning. One can easily spot the victim(s). Glazed over eyes follow frequent bouts of tongue biting; tongue biting that outputs internally rather than vocally. The victim will suggest a bio-break and may blurt out short buffer-bursts such as "Agile" or "Scrum" or "Waterfall sucks". The host of the meeting should grant the bio-break in order to mitigate the victim’s symptoms and prevent gaseous NH₃-based asphyxiation of the other meeting participants.

(for those of you thinking you might have this syndrome... before you call the doc, this - the section "Related Health Issues" is of course, fiction!)

Are you ready for truth? Brace yourself. Take a laxative laced with antacid. Have a beer. Sing along with Milli Vanilli.

Before I expose the simplistic yet shocking details, I recommend surfing wiki to look up Byte, Endian, and Floppy Disk. The origins of those terms underscore just how quickly something so simple as waterfall myth takes root within this industry. See footnote 3.

A SIMPLE TRUTH

One day a bunch of computer geeks were looking at a diagram in an infamous U.S. Military Standard. The diagram looked like a cascading waterfall. Someone said, "It looks like a waterfall." Others chimed in with agreement. The Waterfall was born - again! (see footnote 3). The methodology itself was iterative, contrary to what the diagram suggested. How do you know Jake? I was born and bred on it, on many DoD contracts. I was in meetings where we had the same perceptions of the diagram, "Dang, it's a waterfall!". I do not know or care if any of those meetings can stake claim to lighting the Waterfall fire which has for all intents and purposes has brought many projects to their knees due to all that has been suggested here.

We teams charged with marching to it, marched in iterating circles while Billy Preston sang about it. We iteratively and incrementally cranked out applications that could land aircraft automatically and keep aircraft from occupying the same airspace at the same time. We also iteratively cranked out applications that would help aircraft occupy the same airspace at the same time! We also "jammed" in iterative fashion to the musical signatures of Electronic Warfare. Well Jake, if all this worked, how did the methodology come to be so controversial and misunderstood? Simple! Some people looked at a picture and not the text. The "Not-invented-here" syndrome-headed people got their dollar-squeezing hands on it and operated from the concept of "a picture paints a thousand words" without reading the explanatory text. (Thank you David Gates and those you borrowed from). The bad-mouthing contest began. High-paid consultants convinced the DoD that their consult was worth part of the DoD budget and that "Waterfall" missed the mark. Dilbert was born again! Thank you – not Scott Adams, but U.S. Naval Aviation! (Oh no… another myth busted!) Here is your bonus busted-myth:

Page 16, paragraphs 4.1.1 and 4.1.2 speaks to both the cyclic and iterative nature of the life-cycle. It also addresses "incremental".

As with all standards, specifications, and software - it wasn’t perfect when first released. Refinements and clarifications have shaped it into what it is today – MIL-STD-498. I believe that too has been obsoleted and superseded by J-STD-016.

COMMENTS/LESSONS LEARNED/QUESTIONS

The author reserves the right to revise this!

FOOTNOTES: As is common practice throughout IT, This author reserves the right to invent new words.

Footnote 1: Agilisticated: an adjective meaning: The feet of people in IT hearing "Waterfall" swell with adrenaline in excited anticipation of SDLC confrontation. Blood flow to the critical thinking components of brain ceases resulting in unintelligible buffer blurting via vocal medium.

Footnote 2: Frustigitated: adjective meaning: concurrent feelings of frustration and agitation.

Footnote 3: To further muddy the waters upstream in time, references to the waterfall appear before my time. The first written material to describe the waterfall was made by Dr. Winston Royce in 1970. However, it is not clear if Dr. Royce was the first person to apply a name to an otherwise development methodology without a name. Dr. Royce described a linear succession of phases and would apparently qualify and/or change his description by suggesting iterations in the latter half of the same research paper. It is important to understand that the paper is a statement of Dr. Royce's experiences. The paper suggests development refinements based upon those localized experiences. Likewise, it is important to understand that my own statement represents my own experiences. Am I compromising on my position of waterfall myth origin? No! I am simply referencing another person's work that actually ties a diagram looking like a waterfall to actual usage of the name "waterfall".

Until I discover otherwise, my own experiences are obviously tied to another thread of development methodology refinement already well-cemented as localized iterative development in the US DoD. Still, the various branches of the military were already ahead of the game as evidenced by the many standards promoting iterative development. The large scale multi-system defense application most familiar to me and my first computing job in 1975 had been in development since the early 1960s, with yearly releases of newly integrated applications and refinements to existing applications. These sub-systems were all developed iteratively. I had joined an iterative development life-cycle in progress.

REFERENCES:

http://en.wikipedia.org/wiki/Waterfall_model#CITEREFRoyce1970