> When people scream “this is a bug”, it is irrelevant what it is caused by. It is a scream of a significant expectation mismatch. The team should work on resolving it, regardless of whether it was caused by a developer diverging from the designed intent or because of the original intent going wrong.
As a user, it's extremely relevant to me. I paid for your product/service because of what it claimed to do. Bugs are ways in which it doesn't do that. (It doesn't matter to me if some other hypothetical features don't exist yet, because I was happy to pay for the product/service knowing it didn't have those features.) As far as I'm concerned, a bug is your company not holding up your end of the bargain, even though I've held up my end by paying for it. That's not a good look.
Another way to look at it is that a bug is downtime for a feature. Elsewhere, you say (system) downtime should be #1, "top priority of everyone" until it's fixed. But what good is the system being 'up' if it's still broken in the way that I need? When I lose power at home, it's no consolation to hear "The power grid as a whole is still up -- it's just your neighborhood that's not working", nor would I consider this reasonable justification for de-prioritizing fixing it.
Maybe your company is at the stage where attracting new users with features is more important than keeping existing customers with quality. But they say it's always easier to keep customers than it is to acquire new ones, and I've blackballed several companies because they no longer place the priority on quality that they once did. You should be aware of what you're giving up by de-prioritizing 'bugs', or pretending they don't exist. I see comments here on HN every day complaining about specific companies whose software quality suffers. It takes years to dig yourself out of that hole.
That's what the author is saying though. The classification of "bug vs. feature" is irrelevant to the user, and trying to convince someone to call it something other than a bug to make the developer feel better is missing the point. What matters is something isn't working for the user, and should be made to work.
As a user, it's extremely relevant to me. I paid for your product/service because of what it claimed to do. Bugs are ways in which it doesn't do that. (It doesn't matter to me if some other hypothetical features don't exist yet, because I was happy to pay for the product/service knowing it didn't have those features.) As far as I'm concerned, a bug is your company not holding up your end of the bargain, even though I've held up my end by paying for it. That's not a good look.
Another way to look at it is that a bug is downtime for a feature. Elsewhere, you say (system) downtime should be #1, "top priority of everyone" until it's fixed. But what good is the system being 'up' if it's still broken in the way that I need? When I lose power at home, it's no consolation to hear "The power grid as a whole is still up -- it's just your neighborhood that's not working", nor would I consider this reasonable justification for de-prioritizing fixing it.
Maybe your company is at the stage where attracting new users with features is more important than keeping existing customers with quality. But they say it's always easier to keep customers than it is to acquire new ones, and I've blackballed several companies because they no longer place the priority on quality that they once did. You should be aware of what you're giving up by de-prioritizing 'bugs', or pretending they don't exist. I see comments here on HN every day complaining about specific companies whose software quality suffers. It takes years to dig yourself out of that hole.