Maybe there’s no such thing as a bug. Maybe there are just things that work well and things that don’t work well. And this is true for toasters, dvd players, phones, orange juicers, nut crackers, speed boats, and [insert favorite implement or toy] as much as for software. Life isn’t perfect, and nor are the artifacts of life. No product satisfies 100% of its users.
In software we get all knotted up about “bugs”, and arguing whether something is a requirement, a bug, a new feature, or scope creep. Who cares? Not a rhetorical question. The people who care are the ones who draw up the contracts making promises to customers to complete work to an exact specification by an exact date for an exact price. Which is a form of madness. It is a form of madness so prevalent in our industry that we have mistaken it for normal.
When we step back from this fake reality, and look at real reality we quickly see that life, and products, cannot be defined with any useful degree of accuracy. Both must emerge. So we start having dialogs with the customer, and we start making things, and we say to the customer, “like this”, and the customer says, “no, not really, more like this”. Did we give the customer a bug, or did we give him an artifact to generate better dialog? (Rhetorical question, that time.) In Scrum this is called the empirical process.
There is a LinkedIn dialog going on about how to manage bugs. Half the people say a bug is just another story, the other half say no, it is a special case and must be handled differently. So two backlogs, one for new features and one for bugs. But why stop there? If two, why not three, or ten, or twenty? One for each different type of request. Again, not a rhetorical question, but one that has a clear answer: Because prioritization becomes a farce, that’s why.
When something doesn’t work to satisfaction we (may) need to improve it. But first we need to be asked to do so. Thus a request needs to be made. “Please do this thing for me.” And we can respond, “I’d be happy to. Let’s look at the many other things you also asked for, so we can decide when we’ll do this new thing.” It’s so simple. 
And note, requests and requirements are not the same thing. A request is a possibility to explore; a requirement is a demand. A request opens up dialog; a requirement closes it down. We can eliminate the bug/requirement argument by dropping both terms, and simply using the term request.
Don’t be a slave to bugs. A bug is a small, six-legged creature, and last I looked God made them perfectly to fit the earth’s eco-system. Improvement unnecessary. Let them be. A badly designed or badly made artifact can be improved. Or it can be thrown away and we can make new stuff. Arguing about requirements and bugs and scope creep is futile. All we really need to do is learn how to make clear requests of one another. And then we can explore—openly, collaboratively, and with shared purpose. Amen.
 Liz Keogh reminds us that there are times when this dialog is not appropriate. She cites an example of site outage [ref], and Moss Callum followed up with his own example of seriously compromised security [ref]. In both cases a “fix this now” approach is clearly essential—don’t waste time talking about it. But rather than using these examples to treat all bugs differently, they should be considered exceptions. Sure, there are times to panic, but let’s do it once in a blue moon, rather than every day.