Even master specmeisters know that things change during the course of a project, and I don't know of any that tell a customer "Sorry, no changes allowed". Of course you have to deal with this, because otherwise you'd put the developers in the position of delivering something that the customers don't want and probably won't pay for. That's ridiculous.
But allowing change doesn't mean that you do so casually; unless the customer doesn't mind the meter running all the time, he must have at least some sense for what he wants so that the developers don't get buried with "Let's try this. Or how about that? Or maybe that?".
But worse than wasted time is the bad design that has to emerge. There are certainly minor details that can wait until the project is nearly completed, but more parts than not are really hard to change late in the game.
It's like building a house: you can pick your color scheme at the last minute, decide what kind of wiring you want (cat5? fiber) until well into the project, but the number of rooms has to be nailed down pretty early. And the number of floors even earlier.
Maybe we should try "Agile Construction" to obviate the yoke of floor plans and deciding what you want before you break ground?
I think all these involve-the-customer initiatives are excellent, and most projects already make intermediate deliverables anyway. This is nothing new.
What I see about Agile Programming is an aversion to specifications and making it more human. That's really lovely right up until the point where the customer realizes that his inability to decide what he wants is very expensive.
Are you referring to the mischaracterization of agile development as "just a buzzword"? 
OK, I know you weren't. Read on...
"""Even master specmeisters know that things change during the course of a project, and I don't know of any that tell a customer "Sorry, no changes allowed"."""
Unfortunately, I do know companies that have this attitude.
"""Of course you have to deal with this, because otherwise you'd put the developers in the position of delivering something that the customers don't want and probably won't pay for. That's ridiculous.
But allowing change doesn't mean that you do so casually; unless the customer doesn't mind the meter running all the time, he must have at least some sense for what he wants so that the developers don't get buried with "Let's try this. Or how about that? Or maybe that?"."""
OK, fair enough. But:
"""But worse than wasted time is the bad design that has to emerge."""
This is where we disagree. I've heard this argument before. People claiming that too much change later on "necessarily has to" lead to bad design. I think the choice of language is very important here. I've used systems too (e.g. Delphi) where making changes is just hard, or at least harder than it should be; changing everything the right way takes too much time and is too expensive. So you're tempted (or even forced) to take shortcuts. I believe (and you may disagree) that a so-called agile programming language is a great boon here. By its very nature, it makes change easier. That's not all -- they're not languages that allow for sloppy shortcuts that are not allowed in "real" languages, as some people think. Rather, they allow for a different design altogether. Doing the same design in a non-agile language would be "bad", if it is possible at all.
"""There are certainly minor details that can wait until the project is nearly completed, but more parts than not are really hard to change late in the game.
It's like building a house: you can pick your color scheme at the last minute, decide what kind of wiring you want (cat5? fiber) until well into the project, but the number of rooms has to be nailed down pretty early. And the number of floors even earlier."""
IMHO, design and development is only like building a house if one uses non-agile languages. Now imagine a language and/or methodology that _does_ allow the customer to add "rooms" on the fly, or change room sizes, or add whole levels. Which one would a customer prefer? Rigid or agile?
One could argue that such a "house" would be patched together and has a flawed design -- but what indication, or proof, is there that this is indeed the case? Remember, we're talking a *different* design methodology here, which isn't necessarily worse.
In fact, my experience is that it's easier
In fact, my experience is that it's easier to have "bad design" in non-agile languages, because it's harder to change it once you realize it's wrong.
"""What I see about Agile Programming is an aversion to specifications and making it more human. That's really lovely right up until the point where the customer realizes that his inability to decide what he wants is very expensive."""
Agreed, that can get out of hand. I am not advocating doing no design or no specs at all... I am saying that you can do some meaningful development even with half a spec.
Yet, in the project I am currently working on (professionally), there isn't even a real spec... if there is, it's well hidden. That doesn't mean we just add things willy-nilly... we use a bug report system, etc. Agile development works well here because the system keeps changing, due to changing customer demands, legal requirements, third party needs, etc. I think Paul Graham's "smudge and smear" analogy would apply here, rather than "building a house".
BTW, I don't like the term "agile programming" or "agile language" either... but it's better than "scripting language"... :-/