Bug vs feature

One of the classic software development distinctions is between a bug and a feature. A bug is unwanted behaviour that you have, and a feature is wanted behaviour that you don't have. Which is to say that in many cases, the distinction between bug and feature is only one of perspective. Is "the car loses control above 150km/h" a bug, or is "stable at speeds over 150km/h" a feature? The answer, at least in software, is defined either formally or informally by the expectations of the people involved.

A similar idea holds true about expectations in general. Is "I want to be a famous comedian" a feature you are hoping to implement, or is "I'm not a famous comedian yet" a bug that you need to fix? The answer to that will say a lot about your attitude when working toward that goal. If your current situation contains a bug, it is unsatisfactory to you, and you will need to fix the bug for the situation to be acceptable. If it's a feature, things are acceptable already, but they could be even better in the future. To put it another way, the bug/feature distinction is normative; unlike a feature, a bug shoulds you.

So I imagine it's no surprise that I consider bug-centric thinking very dangerous. It's a close relative of the high water mark problem, in that your perspective can have a profoundly positive or negative impact on your satisfaction with doing something even when the result is exactly the same. Defining things as bugs means things will be okay, but they're not okay now.

And if the future is just a series of nows, that could leave you in a pretty bad position.