Internet & "Fall Of WaterFall "

CAVEAT : I have never developed a single workable software on my own .

(Last program I had written was of "Doubly  Connected  Circular Link list"  I think it was compiled properly but it showed some run time error .so I  copied the code from my friend's program and changed the message in Printf  )  .

I have practically little Zero experience to comment on the things which I am going to write about .  views expressed here are based on my observation as a ring side view of software development at my day  job as a salesman in a software firm  and whatever little I read on Internet . there is good chance that it might be just plain big talks .

Good that you are still reading .. thanks .

FALL OF WATERFALL

 

When I was in college Mr. Pressman told us that best way to develop a software to develop in a waterfall methodology .

Req. Analysis ->  Specification Freeze  -->Design --> Development/Coding & Integration-> Testingà User Handover /Installation . (documentation is common in all these phases) .

Through out the short life of software industry ,from mainframe era to desktop era, waterfall methodology  of software  development was de-facto standard .Names have changed  but essence was same . developer /analyst and evangelist followed this as fundamental  postulate ,lemma #1  of good development practice. The whole cartel of CMM, ISO and other QA standards evolved around it .

In Waterfall  school of thought the main stress is on maintaining a proper development hygiene & Following the strict process . but lately with the arrival of Internet and the rise of web based application development ,waterfall   methodology has failed miserably and some folks claim that this is not the best way to develop web based application . Internet is a new medium and it require a new set of principal .  does it ? or it is just a hype ? lets see

 

PUSH(S)  IN THE FALL :

a)       Rapid Prototyping : ->  Waterfall way of software development  is based on the assumption that you can study the requirement deeply first and than freeze the specs. from there on you only have to implement . But this, I believe is a fundamentally wrong way to approach the problem of software design . To study the requirement it is not enough to,  "study " it  on a one time basis  and try to design a solution . you will surely miss something .  To come up with a good design you need to live the problem  for some time .

You can argue that there are domain expert who have "Lived" the problem for  long time . but the problem is that  in "waterfall " the interaction with these domain expert is very structured through manuals and other documentation.The very process block the flow of  ideas and counter productive in the pursuit of understanding the domain .

So lets admit that in a typical IT project the knowledge transfer  from domain expert to designer is crappy, formal and very basic , it can't bring AHA moment to end user .  problem is more severe  because once the specs is finalized they can't be changed till the next version . so you can't make (basic )correction  en-route . much of this constraint is due to the fact that software is distributed across a wide user base and upgrading them every six month is not feasible .

But in web based application this problem is not there . so they can afford to what is called "Rapid Prototyping " . loop of "Feed back -> Correction-> Feed back " make us easier to reach the ideal prototype soon . Real power of Internet here is that it work as an instant distribution channel . so a true collaboration is possible only on a web based application . this is one of the reason "Water fall "  is out of fashion  when it comes to web based application development . it is not aligned along the grains  of  Internet . it doesn't exploit Internet's capability as a collaboration and distribution  platform .

 

b)       Failure Mode Analysis : Waterfall preaches that success is about following the best practice only. But experience tell us that as much as it is about following best practices, it is by equal means depends on  avoiding  individual case of failure also . every text book of computer programming preaches that we should first design flow chart and do a dry run on notebook and than punch in the code . honestly how many time you have done it . we write a program first  than optimize it to avoid individual case of tripping. I call it Failure Mode Analysis (FMA)  and this is most efficient(not correct or ideal )  way of developing the software  .  a development based on this method is only possible for a web base application  .

When it comes to FMA ,Waterfall expects a lot out of Testing  team but I have noticed  the testing function with in the constraints of design . you can't rectify  a design level mistake through a post implementation testing .So we mostly glorify design level goof up as implementation constraint .

 
c)       Development Democracy :  Waterfall treat software development a very sacred,ritualistic endeavor where End User is passively involve . Most of the times expectations are not clearly defined and understanding about requirement is hazy . most of the time working hypothesis is "If End user accept  the final application ,good if he doesn't accept "Very Good " he should wait and pay for new version" .Web based applications are "For The User ,By The User & Of  The User " . they bring in the sense of shared owner ship and community between developer and end user . which works wonders in faster adaptation of software .

       

           Conclusion :   based on the arguments I have presented above  I conclude that water fall way of developing software is not suitable   for web application development .For any software to be a good software it should revolve around user . I will end with a little of f –the –track story  .

Have you ever read   "War & Peace "  (A Great Software )? It was written by Leo Tolstoy who was soldier  in Russian army and seen the WAR for twenty years on first hand basis.  he knew the price people pay for WAR . then  he lived in peace for another 20 years to see the price people pay for peace and than he set down to write a book ( living the problem) . it took  him some years to write the book and he always incorporated his day to day observation in plot . his Epilogue shows that book's plot was not frozen it was up-to- date and relevant (Rapid Prototyping ) . At that time only a handful of peasants &  common man in Russia can read and still the book is not only about army , politics or govt its about people ( Democracy ) . perhaps that's the reason  we still  read "War & Peace " & forget other regular  book after one month of reading it .  It seems Mr. Tolstoy understood it long before our software guys

P.S  Thanks for reading  . I welcome & Value  you comments