Shipping Software and Broken Windows (John Lawrence, MS VS Team System blogger)
I'm afraid we have the opposite problem - if it looks great, the customers (and sometimes the management) tend to assume that all the code behind the UI is done. Having the germ of something that works is great for the coders' morale, but you get a boatload of "what do you mean it isn't done yet?"-type questions. This happens particularly if the requirements were vague and the UI's been done as a way of investigating the workflow.
One of my colleagues has seriously suggested building the UI nearly, but not quite, right, then logging a bunch of bugs against it. That seems wasteful to me - I'm of the 'do it right first time' persuasion, within the limits of your current system knowledge.
The UI/code relationship is a bit of an iceberg, really. The bit the user sees is only 10% of the whole - they never really know about the 90% that's under the surface.
[Edit: Darn, I thought that was a really original analogy. But Joel got there first.]