It may be true within big companies that you should keep expectations low by making your prototypes look bad, but that's just further evidence big companies are broken.
In our UI class we were taught that if it is a prototype, that it should look like a prototype.
The concern was that if you over-do the UI to make it seem in between a prototype and a finished product, then you are confusing yourself and others judging the design whether to take this as a finished product or a prototype.
That makes sense. If I want a critique of my application's layout, then giving colors to buttons isn't a good idea since I just want feedback on the layout. The colors are just a distraction.
It's not about looking 'bad' vs 'good', but finished vs unfinished.
You're mixing two related but different things: managing expectations in order to prevent disappointment, and accurately conveying the maturity of a project in order to get suitable feedback. Unfortunately, the article starts as if it was just about the first aspect.
In zaidf's example, the button colors not only are a distraction; they actively inhibit criticism to the layout. Unconsciously, the 'cost' of criticising the fundamental design features (layout) has raised, since changing these implies having to rethink many of the details designed on top of them (color of the buttons, or whether you'll be using buttons at all).
Someone with design experience will be less shy about asking you to do big reworks. Design professors are all too happy about this. But most people will block criticism in a direct correspondence of the rework it would involve. In big companies, that may be a conscious political decision. In startups, it may be an unconscious bias due to social factors.
It seems to me that the concept applies whenever you're trying to get feedback from non-programmers; big corporations or not.
If you're demoing to an investor, on the other hand, you should try make it look really good. You're not asking for feedback, you're trying to impress.
I want to take a stab on solving the parallax between what the blog author writes (which I love) and pg's comment above (which I also love.)
Most YCombinator founders (and YNews readers) are young, and venture capitalists or techcrunch readers know this. Every ounce in any skill set that shows we are competent helps sell us. Anything, be it as little as a great visual prototype, helps.
On the other hand, this article discusses how the non-silicon valley customers, managers, and investors (even Microsoft) will confuse images with reality. An even bigger problem is that the author assumes all programmers will be using a desktop programming language (with no frameworks) in most articles I've seen on that web site, not realizing that web frameworks allow anybody to have something up and running within a week. I think this advice would be more true pre-Ycombinator and pre-web framework days (in 2004.)
I trust that both observations are genuine; and, on a personal note, I prefer pg's attitude more, because I like hearing when people denounce or offer alternatives to "plan for the lowest denominator no matter what" type of business blog advice.
This has never been my experience. If your managers can't believe you when you say the gloss is just good design and not a sign of completeness, get a new manager.
If your manager doesn't understand anything about infrastructure, and reacts to a poor interface with talk of program cancellation, get a new manager.
