There is a difference between complaining, voicing opposition and articulating trade-offs less technical people may not be familiar with.

Eventually customer got tired of having to defend how many statuses he wanted in combobox or what process their company want to use.

By that I want to say, there is definitely such a thing as programmer not willing to consider business point of view for a second and thus being impossible to work with.

It is vital to understand business needs. A lot of times businesses want changes that are hard, and very hard to implement. It is our responsibility to work with the customer to come up with a solution. The customer must accept the consequences that come with their requested change.

Unfortunately, some things are impossible to do. It is never good to be the bearer of bad news - I have myself told that we cannot do it this way, but I have always given a thorough explanation of why it is impossible and suggested workarounds and alternatives. I think sometimes this behavior can be the difference between the perception of being impossible to work with and helpful.

Truth is, it takes a lot of effort to balance your work against the ever-changing set of requirements coming from your stakeholders.

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.

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).

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?

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.

If the problem is that the issue hasn't been explained well enough then the developers need to work harder to better explain what the problems are and why they're problems.

If the problem is that the business person doesn't have the necessary background to understand the issue then you have a huge problem. That person is going to be a problem at every step. I don't envy anyone in that situation. In the past 25 years of development I've never actually encountered that situation though.

Unfortunately, some business people are compensated as direct function of revenue (growth), even though they have to pull engineering levers to obtain that delta in revenue.

For a lot of these people, once they’re convinced that doing X will lead to growth, no explanation will convince them that it isn’t worth it.