Coding Over the Waterfalls
I recently challenged the continuing relevance of the "waterfall" model of software development in a column for our eWeek Labs e-mail newsletterI recently challenged the continuing relevance of the "waterfall" model of software development in a column for our eWeek Labs e-mail newsletter (enewsletters.ziffdavis.com). An old friend and fellow LISP hacker fired off a rebuttal that began, "I guess the industry will just never learn." Can he persuade you? My friend objects to the suggestion that requirements-driven development cant keep up with Web speed. "You cant build a stable, reliable Web site or any kind of system without adequate planning," he asserted, adding, "The original waterfall paper addressed the need for iteration and breaking projects into subprojects, milestones, etc." Yes, I have to agree that statements of requirements have to come before the writing of the first line of code. If the working application has to serve as its own specification, theres no way to tell which of the softwares behaviors are intentional.
The problem, though, is that the waterfall models a one-way flow from requirements toward working code. Rapidly changing e-business technologies, not to mention competitive environments, demand a dialog between deliverability and desire.