[watwut]

It was not issue of ambiguity. Specification was clear. It was issue of programmer assuming that customer is wrong all the time and basically wanting the customer wrong. The statuses were right, but the programmer fought to merge few of them into one, because it looked "simpler" to him.

By questioning in don't mean having honest questions nor trying to understand, but being convinced that there must be mistake and forcing customer to defend every tiny choice.

And sometimes the customer wants radiobox instead of combobox are just wants to have it without having to spend 20min on meting to defend the choice.

[agentultra]

On the other side I've had customers ask for things that are impossible or against best practices and their own interests.

For example, password requirements. Many companies are not aware of the latest best practices and guidelines and request that we block browsers from generating or remembering passwords in password fields. Or they give us a list of draconian password requirements that are clearly debunked by the latest guidelines.

Or they ask us to basically break the HTML spec.

Like I tell my four year old son, I'd love to get a million dollars but I'm not going to get it because I stamp my feet and demand it.

Trade-offs need to be made on both sides. I agree that an engineer that doesn't provide alternatives when a customer demand is not technically feasible should be corrected. However the customer should be prepared to choose from those alternatives or change their demands as well. The first step to success is shipping and the most common reason for software projects shipping late is a failure to start. I'm not against firing bad customers.

It's much easier to ship without a contentious feature and figure out how to add it later than to delay shipping (for certain features within reason, of course -- please don't ship half-baked security libraries or aviation control software).

[watwut]

Yes, but that is different situation.

I was specifically talking about situation where requirements are possible and not ambiguos. And where engineers starts "knowing" customer is wrong and keep knowing it despite it regularly turns out it was enginers lack of domain knowledge.

There is no trade off between these two situations.

I don't know what you mean by breaking html spec. Browsers keep it and we work either with it or around it?

[agentultra]

Ah okay, that makes sense.

re: HTML -- I've had strange requirements come in that required us to work around the HTML spec in order to get the UI to work they way they wanted. We eventually found a better solution...

but the point was that not all requirements are golden; sometimes the customer is plain wrong, ignorant, and stubborn.

[watwut]

Yes, I agree with that. It is not that customer is always right. But it is not that customer is always wrong either. We have to look at requirements, give them benefit of doubt, ask and listen to answers to figure out which are wrong.