What's broken are humans. For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished. There's no way around that flaw in people, so making prototypes look unfinished is something we have to do anyway!

Perhaps because “unfinished” offers stakeholders the opportunity to make major contributions, whereas “finished” means it’s already too late to make changes now so anything they do say will just be ignored.

Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.

It's an example of the Doorway Effect: brains are wired to work in modes related to context cues. Change the context, and you'll change the memories and trains-of-thought easily accessed.

Polished things have a context of "use", not "evaluate", because we use so many polished things every day, but very rarely have any need to evaluate them (mostly only when we're buying them, or when a repair person asks us to describe what's wrong with them.) Whereas unpolished things are mostly "for" evaluating; it's rare that people use unpolished things (outside of, say, disaster-relief infrastructure.)

> For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished.

Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.

Here's another way of thinking about this:

it's not a way of gaming the system, but a way of prompting better feedback. For instance, in a Design Thinking process prototypes are more useful when they look rough/unfinished. A more polished piece of work might result in people being afraid to break things.

I use both approaches in my work:

1) demo small, tested bits during show and tells and any meetings where the point is to demonstrate progress. 2) demo large, unfinished and barely stable pieces of work when ideating, trying to figure out the next steps

2) is hard and works only if: - we know what the unstable parts are (because we have tests, so we know the gaps) - we know the audience and how much context they have

I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback.

The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.

If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.