eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I 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.
If youre landing a man on the moon, you cant downscope your goal to merely getting him there; President Kennedy was careful to include the key phrase “and returning him safely to the earth” in his first statement of requirements 40 years ago this spring.
But when youre establishing an e-business presence, you cant allow an overly ambitious requirements statement to hold up your arrival on the scene. You have to be able to paddle upstream, if need be, and take a different path if the one you first chose turns out to be too long: to practice white-water kayaking, rather than just going over the waterfall and hoping youll like where you land.