Slashdot

Yeah - I had to sit through a two hour session online plodding through a MS Partner Program exam that crashed at - yep - two hours in. And the only solution was to start over.

Ugh.

That's definitely one source of benefit. And generally, people are happy to give it. There are a variety of beta-quality products I use, and am glad to give early feedback because it helps me get a product more in line with what I want. When I don't have the time to deal with beta-quality stuff, I pay up for a finished product.

From a developer perspective, I love this, too. You never really know what people are going to do with something until you give it to them. If you're Microsoft, you'll sit there piling up several years' worth of guesses, and then find out all at once how you did. I think it's much safer and saner to release early and often, so you can correct your small problems before they become big ones. If I had to pay users to do that, I probably would, but so far, there seem to be plenty of free ones.

I disagree. I think agile development (not web 2.0 - whatever that is) is really a useful methodology. Rather than developing the product for an extensive period of time and finally confronting the customer with what you've cooked up, you periodically show them what you've made and let them provide input on future directions. As a customer, I would like that. I can see progress is being made, and I can spot early if things are going in a direction I don't like.

On the other hand, I have come to appreciate the waterfall model as well. It's good when you know in advance what you want, and it makes it easy to assign different people to work on different parts of the system. When done right, I think it can save a lot of overhead compared to agile development, and you know what you will finally end up with. As a customer, I would value that, because I can go about my business while the software is being developed by others. I'd still want to check on them once in a while, though; something that most customers I've dealt with actually don't seem to do.

So I think both models have their strength. Waterfall is good if you know or can determine in advance what you want built. You analyze the requirements, design the beast, and implement it, and if the specification was good and the devs and testers did their job, you'll have a product that does exactly what you ordered. Agile is good if you don't exactly know what you want. It fits an evironment where there is lots of innovation or competing products - you'll want to add features as you go, in response to changing ideas of what you think will drive customers to you. Waterfall is awful for that, because your product will be outdated by the time it is finished. On the other hand, agile doesn't give you much of an indication of what you will eventually end up with and what it will cost you.