The 'fall' of the Waterfall Model

The first time I heard of Waterfall Model was when I was an undergrad under the Software Engineering course module. I was like going "wow" when I first become acquainted with this course. Why? It sounded like candy to the green ears of impressionable undergrads.

Fast tracked 7 years down the road, I have seen projects way behind schedule while some are falling apart, bogged down by its own stress. Seasoned programmers will tend to agree that late delivery is inevitable in software development.

To explain the delay, project managers will shrug it off as the 'norm' or maybe some mysterious office-monsters ate all the computers in the office. Team leader or architects will complain lack of resources or maybe the requirement specs are pure bollocks to begin with. Programmers will simply complain that they only have 24 hours per day in their life and they need special privileges as they are 'different' from people in other profession. Sounds familiar?

In the midst of all these chaotic processes to churn out quality codes, the users or clients will drop by and make our lives miserable (as if we are not already!!) by passing a additional set of requirement to our superiors. Behold, the common dreaded word - CHANGES.

Trying to look as if any wrong decisions will stop the sun rising tomorrow, the standard reply will always be "Let me bring this to my architects and their teams and we will reply asap....". Why they even bother to even ask us remains a mystery?

• This is an excellent money-making opportunity for the organization. Every changes will incur additional manhour sweats (ours!), which will obviously mean more bloated invoices for the morons...oops..clients.
• Our schedule will always be delayed. What a good way to justify that the delivery need to be extended due to such changes.
• Customers are always right. Even if they claim the sun is a square cheese up in the sky, who are we to deny them.
• Or maybe we are simply damn cursed to have a splendid boss who have perverse pleasure in making us work through the weekends.
  

The architects and analysts (or whatever you like to call them..) will bore down on their schematics and designs, speculating on the impacts, asking themselves to include thos changes at the current phase or bring it later to the next phase, hoping it will not screw up the system.

Like it or not, we peons (yes I mean you too!) have no say. The only thing is to curse silently (I prefer to just open up a chat window to a random member in my messenger and do a cyber-scream) whenever we need to re-work our codes. I may hit a chord with those nay-sayers, proclaiming that if our designs are done modularly, there should be minimum refactoring..blah blah blah.

Yeah right! Funny that usually those so called consultants are the very idiots who keep producing theoretical but impractical designs. Or maybe I am simply unlucky! There must be some folks in my corner of the world who can at least produce humanly proper designs.

It took me a while to come to a conclusion, that the current process (Waterfall Model) we keep on slugging simply does not work. It looks nice on paper, but it is so not ready for its archenemy - CHANGES. What?! Even after being first published in 1970, it's still not ready?? After nearly 40 years?!! Gasps!

A simple illustration describing the model.
I will not touch on the description of the model. Just google it and there are vast resources for you to look at. However, what is interesting I found in its Wiki is the statement below.

The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995),^[1] although Royce did not use the term "waterfall" in this article. Ironically, Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development - as a way to criticize a commonly used software practice.

SO WHY THE BLOODY HELL ARE WE STILL USING IT THEN???!!! A nice link about their main drawbacks here.

I will give a quote from Scott Rosenberg's book "Dreaming in Code". What I would like to point out is that by the time a complex project is finished, usually there will be major breakthough or new technologies.

For decades the organization of the typical project followed the "waterfall model." The waterfall approach—the label first surfaced in 1970—divided a project into an orderly sequence of discrete phases, like requirements definition, design, implementation, integration, testing, and deployment. One phase would finish before the next began. This all seemed
logical on paper, but in practice it almost invariably led to delay, confusion, and disaster. Everything took forever, and nothing worked right. Programmers would either sit idle, waiting for the requirements, or give up and start design work and coding before they got the requirements. "Big design up front" led to big delays, and "big-bang integration"—writing major chunks of code separately and then putting them all together near the end of the
project—caused system collapse. By the time the finished product arrived, so much time had passed that the problems the program aimed to solve no longer mattered, and new problems clamored for solutions.

Currently I am in an organization where we are experimenting on Scrums (Agile Methodology).
Its far too premature to provide a clear comparison, however the signs are good, although I find it quite loosely defined and quite prone to abuse. Hopefully I will sit down and write about this after undergoing a fair amount of sprints.

I am not condemning waterfall model actually. Well not too much really. However, I think it's time we review our process and also break from the "follow the crowd" paradigm. Although the model is here to stay and will not fall as I try to overdramatize in this blog title, I have high doubts (I may be proved wrong) and I still question any organization that adopts it, other than the fact it produces nice eye-candy documentation.

Forgive the pun as I enjoy this...Waterfall has fallen!