Is this a bug, a missing feature, or neither?

Software makers have this question a lot.  They get some feedback from a user, and they must decide if it’s a bug, a missing feature, or neither.  In this article I will explore this question using the analogy of a car.  The simple answer is that there’s a lot of nuance – i.e. ‘it depends’ again –  and this can lead to less obvious consequences.

My car doesn’t fly

First, we will imagine that the feedback from the user is: my car doesn’t fly.  Is this a bug, a missing feature, or neither?

One of my favourite definitions of bug is the one I learned from Michael Bolton: anything that threatens the value of the product for someone who matters (I’m paraphrasing slightly).  As good as it is, it doesn’t give a foolproof set of simple steps to follow to help you decide.  In this case, a car not flying threatens its value to the driver, so that seems to be a bug.

However, is it reasonable for the driver to expect the car to drive?  If they’re driving Chitty Chitty Bang Bang, a top-of-the-line DeLorean etc, then: yes.  Such a car could reasonably be expected to fly, and so it not flying is probably a bug, just as any car not driving along the road is a bug.

Let’s assume it’s not one of the cars mentioned above: now what?  It seems that it’s not a bug, which means we should consider if it’s a missing feature.  This becomes a product management problem or even product strategy.  Yes, we could add ‘Make it fly’ to the product backlog for the car, but does that make sense for the car or even the company?  If I tell a cheesecake manufacturer I’m disappointed that their cheesecake isn’t also a word processor – am I being reasonable?  So, it might be a missing feature, but that doesn’t mean it will be implemented soon if at all.

Before we leave the flying car question, it might be that, despite not being Chitty Chitty Bang Bang, it would be reasonable to expect that the car would fly.  This could be because the salespeople you’ve dealt with, or the marketing words, images and videos you’ve seen etc. led you to believe that the car would fly.

I understand the need to sometimes tell a future truth in sales and marketing, i.e. say something that isn’t true now but will be in the future, as if it’s true now.  However, all the important people in an organisation need to agree on how far into the future it is reasonable to pick as your starting point for truth.  So, the bug could be in the sales or marketing organisations, or in the disconnect between them and the product development organisation.

My car doesn’t start

This is a bit of a rabbit hole, and we might end up with it being a bug or user error.  To start with it seems clear that this is a bug (and certainly not a missing feature).  It’s reasonable to expect that a car will start.  However, it’s not reasonable to expect a combustion engine car to start when it’s out of fuel.  I.e. this could be just user error (forgetting to fill the car up) and neither a bug nor a missing feature.

It might be that the user has filled up, but there’s a leak in the fuel system (a bug).  It might be that there is no leak and the user hasn’t filled up, but they weren’t aware that they were low on fuel.  The sensor that says how much fuel is left could be faulty (a bug) or how the fuel level is reported to the user could be faulty (another bug).

So, it might be user error, or it might be a bug caused by several different things.

What does it matter?

There are several reasons why the answer to this question matters.  The expectations a user has of how soon things will be better are likely to differ if it’s a bug or a missing feature.  This will feed into how near the top of the To Do list the work item goes.  Should this work be done at all (adding word processor features to a cheesecake)?  Is there an organisational bug?  If so, where?