There is a war going on in the world of software development. The battles have raged for decades in universities, software companies and anywhere where two or three software professionals have gathered to discuss their craft. It's a war that has been hidden from normal people until quite recently.
The war is best described as a battle between the Waterfall Model and the Agile Model.
The Waterfall Model was famously described in a paper written by Winston Royce in 1970 titled "Managing the Development of Large Software Systems". Many people who have not actually read the paper assume that it validates the single pass waterfall model when in fact it explains why this model will only work in the simplest possible cases.
Royce was actually a supporter of iterative development as can be seen from these comments made by his son:
He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government-contracting models (a serious set of constraints).
So why do people still believe in the Waterfall model?
The Waterfall model is originally invented by Winston W. Royce in 1970. He wrote a scientific article that contained his personal views on software development. In the first half of the article, he discusses a process that he calls “grandiose”. He even drew a figure of the model, and another showing why it doesn’t work (because the requirements always change). This model is the waterfall. He used it as an example of a process that simply does not work. In the latter half of the article he describes an iterative process that he deems much better.
OK, so why do people still advocate the waterfall? If you look at the scientific articles on software engineering that discuss the waterfall, they all cite Royce’s article. In other words, they’re saying something like “The waterfall is a proven method (Royce, 1970).” So they base their claims on an article that actually says the opposite: that the model does not work.
This is how science (unfortunately) often works - researchers just cite something, because everyone else does so as well, and don’t really read the publications that they refer to. So eventually an often cited claim becomes “fact”.
The Agile approach is seen as the people friendly, team based, flexible antidote to the waterfall model, but the truth is not quite as simple as that.
Anyone who has actually delivered large scale software systems that actually work, use a methodology that is between the two extremes which could be book-ended by Single Pass Waterfall at one end and Extreme Programming at the other end.
What about Usability?
This religious war is now being fought in the open as more people involved in software development have been blogging about how they actually do it. If you want to understand how the process works then I recommend that you read Jensen Harris' blog aout the development of Microsoft Office 12.
Usability testing is useless if there isn't an opportunity to use the knowledge gained from the testing to improve the next iteration of the product.
Usability professionals cannot sit on the sidelines and wait for the suits and the geeks to fight it out. They must get involved and ensure that the methodology adopted allows for User Centered Design practices to flourish and give the software development process the human aspect that is needed to create great software.
You cannot sit back and complain that the development process doesn't allow usability testing results to be used to improve the software because the geeks say it's too late to change the design.
Adopt a geek and find out about the software development process they use. It may be the best way to try and influence the direction of the product, system or feature that you are trying to improve.
If you want a more light hearted discussion of the issues then you might like to attend the Waterfall 2006 conference in April.
Excellent comments! I'm seeing this on my current project. There is a need to be proactive, more than ever.
Posted by: John S. Rhodes | February 13, 2006 at 07:46 PM
Great article! The world constantly changes, that's why requirements often change. When requirements change, waterfall model is falling apart. You simply build a thing that fits the past.
Posted by: Jesper Rønn-Jensen | February 12, 2006 at 09:26 AM