Your users are complaining about an unusable feature in your product. It’s so unintuitive and impossible to understand that they are calling it a “bug” in many angry emails to your support staff.
When the discussion reaches a coder, the issue suddenly gets reclassified as a “badly-designed, but correctly functioning feature”. Out of nowhere, they have rid the problem of its shameful “bug” association and made the whole situation seem a lot less troubling.
Coders fiercely argue that if the feature works as intended — regardless of how unusable it may be — then it is not a bug.
It doesn’t matter that your users can’t figure out what the heck to do with it. Or worse, they make incorrect assumptions about how it should work and get totally surprised by some weird side-effects it causes. For a coder, a bug is something completely different, like an exception or a computation error.
The distinction between a “terribly-designed but correctly-implemented feature” and a “bug” exists only in the coder’s mind. It is a distinction they create due to their professional immaturity. What they are really saying is, “Well, someone else may have designed it badly but I implemented it correctly.” Their focus is on their own priorities. The success of the team, the product and the company are secondary.
Allowing a usability issue’s seriousness to be disregarded in this manner is harmful. Apart from the fact that the issue will very likely get pushed to the bottom of the priority queue, the team could also start to consider your user’s opinions as being less valid than their own. Once that happens, the inmates will be running the asylum. You’ll have a system built by programmers, for programmers.
Engineers however will listen to their user’s complaints and quickly agree that it’s a bug. No debate. If the feature doesn’t work for the users, then it doesn’t work at all. What matters is that it gets fixed.
So how can you help a coder change their attitude towards usability bugs? One method is to have them sit and watch a new user flail around trying to use the feature in question.
But my favorite approach takes almost no effort or time at all. Just ask them,
If this was your competitor’s product, would you still defend it as a working feature?
More Than Coding 
> If this was your competitor’s product, would you still defend it as a working feature?
As a programmer, I’d say, no, I’d leave it to my colleague to defend it as a working feature. Or, if we were on good terms with each other, I’d say, yes, I would.
The programmer’s client is the instance that defines the features that the programmer is to implement. And not the user. (And the competitor is the colleague.)
And if you’d tell me something about another company as competitor of our company, I’d show you the four e-mails I sent to my team lead predicting what the users would say about that. And his two responses, that this feature is BAD (Broken As Designed) par ordre du mufti. And say, I’d call it a broken feature indeed, but wouldn’t blame the poor wretch that was just doing what (s)he had been told in spite of all precience of what the users would think.
(I was lead to this site only today, by a link on thedailywtf.com.)