[baak]

I haven't been doing this for very long, but so far I've found every client who wants software built either:

a) Doesn't know exactly what they want. b) Doesn't know what data is available exactly, or what it means/corresponds to.

With those two considerations in mind, I find anything Waterfall to be exceedingly difficult because I can't possibly come up with perfect requirements up front. And yeah, I know it would be best to spend all the time in the world trying to figure everything out perfectly up front, but it's simply not possible. It's not just my time I'm eating up, it's my client's time as well.

It's better to get as good as I can get without hitting diminishing returns on requirements gathering, then to present the client with incremental milestones, so they can play with it and give feedback, and I can adjust accordingly.

I also really don't like waterfall because at the end I have to say "Hey, here's the requirements you we agreed upon, here's the contract! You can't be mad." I think if at any point you ever have to bring out the contract, then you've massively failed in pleasing your client. Even if you're right, they're still unhappy.

[cateye]

Yes, this is exactly also my experience. But in both cases, Agile or Waterfall doesn't really makes any (form scientific perspective significant) difference.

I've also experienced clients that just can't judge an iteration without seeing the whole application working. Or that a client changes his mind after seeing each iteration which can be more painful then changing just the spec.

As I suggested in my blog post, the book "Making Software: What Really Works, and Why We Believe It", the chapter "Architecting: how much and when?" by Barry Boehm treats this specific subject really well.