Disclaimer unnecessary. I love good debate. And yours is good. A few counters.

1. But you do not have to construct something in its smallest-detail before you can show something...

   I agree entirely. That's exactly what prototyping and RAD are all about. Put together a minimal system as quickly as possible and get feedback before moving on.

2. It does no good to be “quick to market” with what you think to be “finished code” when you are destined to discover that the code you hastily built is ... wrong.

   It does much more good than being slow to market...and finding what you built is wrong.

   You have time to fix it. Maybe start again from scratch. Maybe 2 or 3 times if need be, and still be there before your slower rivals.

   And, in the meantime you won mind space with potential customers.

3. In the business that I ran for 15 years, we made fixed price, time-definite task-contracts on everything.

   It sounds like you had a fairly specific niche in which you excelled. You had a formula for putting together projects that worked, and you re-used that formula over and again. In those scenarios--I'm guessing web work, but web or not--where you have an essentially standard set of requirements--with customisations and variations--it is possible to construct quite detailed plans and schedules up front. (My 100th similar project quote from above)

   Again assuming web work. Let's say you've been buzzing along for a few years putting together custom web sites using mod_perl and Apache and Mysql. You've become very good at estimating delivery times etc. Then a customer comes along and throws a nice buzzword at you: AJAX.

   They've no real idea what it means, but they were shown a couple of Web2 sites. Google Earth, gmail, and a few others and they really like the apparently refresh-less nature of the presentation. They've no idea how their site will make good use of the facility, but they want it anyway. And they seem to have a lot of cash to spend and a lot of new projects in the pipeline. You want some of that business. You have no experience with that kind of site. (A situation a lot of web implementers have found themselves in in the last year or two.

   Now, you have to do R&D. You have to do it in order to get your first feel for the technology and what it is capable of. You have to do it to get experience of how it changes your formula. You have to do it in order to show your customer the possibilities. And to get them to reach a decision about what they actually want.

   You cannot put your plan in place, write your specifications, or even gather your requirements until your customer make up their minds. Until you have made up your customers mind for them.

   That when not just short stages, but indeterminate plans are impossible to avoid. You have to put together the minimum effort and get it in front of your customer fast. It's the only way you can afford to progress.

Even if your niche wasn't web work, a similar analogy of new technologies messing with existing formulae can be constructed for most markets. Even big iron code has gone through a sea change over the last 5 or 10 years with customers expecting java or web based front ends instead of 3270 green on black; and massively parallel back-ends instead of linear.