Is it fair to refer to a feature that has not yet been coded as a "bug"?

For example, I am working on a project that involves three distinct features. If I only start one of them, is it correct to refer to the other two as bugs? Or do bugs only apply to features that have been coded and tested?

  • 9
    Bugs are "undocumented features".
    – S.Lott
    Mar 15, 2011 at 15:47
  • There are features, enhancements, and bugs, usually in the decreasing order of scope / risk. It is very important to know the distinction, because depending on where you are in the release cycle, you would have to say NO to some type of change (unless you do not mind getting blamed and fired soon). Hopefully I do not have to explain how an enhancement is different from the other two.
    – Job
    Mar 15, 2011 at 15:58
  • If the user guide has the feature, then it is a bug: in the user guide!
    – CMR
    Mar 16, 2011 at 2:40

16 Answers 16


It seems pointless to refer to the missing features as bugs while you are still in development.

If you were to release the product without these features then it could be regarded as a bug that they are missing - as the software doesn't do what it's designed to do.

  • Features are features. They are the desired functionality. Mar 15, 2011 at 16:30
  • 1
    But only "could" - really it would be wrong to call a missing feature a bug unless its a failure to do something that the UI claims is going to happen
    – Murph
    Mar 15, 2011 at 16:31
  • 1
    That makes sense. A missing feature can be considered a bug if the testers have a reasonable expectation that it should be in the software at that point. Mar 16, 2011 at 4:03
  • That being said, we could start a whole new Q&A thread on what constitutes "reasonable expectations." Mar 16, 2011 at 4:05
  • If a promised feature was not included in the prescribed release, would the customer accept the system? Would they be obligated to?
    – JustinC
    Mar 18, 2011 at 3:08

You should avoid talking about bugs vs. features, as this implies a qualitative difference for the user, while there is no such thing. From a user-centric perspective, whether something is a bug or enhancement is irrelevant, because in both cases the user is unable to use the product. If it helps, you can think of bugs as unfinished feature developments.

There are only issues, as in "users have issues running your software". Put all your issues on one list with one set of priorities. This way bugs won't come in front of enhancements with higher priority, and enhancements won't come in front of bugs with higher priority.

  • I might argue that bugs should always have higher priority than new features. Primarily because the longer you wait to fix them, the more difficult (and costly) they become to fix. Adding new features can add new bugs that compound the existing ones. Mar 16, 2011 at 12:17

This is why I hate the idea of breaking things down into bugs and features. It leads to arguments like this that are distractions from actually getting useful work done.

Call everything Tasks or Work Items and move on with life.


God, this sort of thing makes me crazy. I want to step through your screen and stab your manager, whom I presume is driving you to ask this question.

Here are my definitions:

  • unit of work (or story): An incremental, releasable improvement to the product
  • feature: Something useful to the user, generally built up from multiple units of work
  • done: When everybody agrees a unit of work is releasable
  • bug: When a released unit of work diverges from what we all agreed it would do

If a product person didn't ask for something? That is not a bug. If they asked for the wrong thing? Also, not a bug. Vendor releases a new platform that we need to do something to support? Not a bug. If a user figures out something that would be a nice improvement? Definitely not a bug.

The reason this is so important to me is that teams should shoot for zero bugs. It's a bug if the team aims and misses the target. It's not a bug if the target isn't even in sight yet.


I would say that a missing feature is a bug in the case that the lack of that feature breaks your program.

In this case however, it'd be hard to call them bugs, since the project isn't yet in a working state. Or, if it is working, and the lack of the features isn't breaking anything, then they're just unimplemented features.


I'd track features and bugs differently. You still have a queue of work you need to get through, but a bug is when the system is misbehaving. If in your implementation of the first feature you made a mistake, that is a bug. The fact that the other two are not implemented yet doesn't matter. They are features that are still being worked on.

  • "...bug is when the system is misbehaving..." or behaving as designed and intended by the developer but not intended by the customer. Mar 15, 2011 at 15:57
  • 1
    Yes, that's a specification/design bug. That's the type of bug that iterative development is designed to weed out while it is still cheap enough to fix quickly. Mar 15, 2011 at 16:31
  • ...or a communication bug...;) Mar 15, 2011 at 16:32
  • And I would not - 2 systems for tracking = bad. See separate comment. Mar 16, 2011 at 7:51
  • 1
    @quickly_now, I didn't say use different systems for tracking. I said track them as separate things. That's an important distinction. A single issue management tool allows you to classify your issues as to what they are: feature, bug, infrastructure, support request, etc. You use the same tool, and you customize your reports to include what you want. However, a new feature and a bug are different things. Mar 16, 2011 at 12:13

The definition of "bug" is rather fluid and has been ever since Grace Hopper found the dead bug inside the Mark I computer. (yes this may be an appochryphal account)

From a user's perspective, an unimplemented feature could be considered a bug, especially if it is the very feature that they want to use right now.

You really need to have good communication with your end-user/customer/stake-holders about the current state of your software. Why say in development when you much more easily say that it is an alpha or a beta version (or my personal favorite - a beta of a very early alpha version...)


IMHO it's not appropriate, but people will still do it. You'll also get this for certain decisions (in particularly in the UI) that are not bugs.

The primary reason is that most people perceive as a bug anything that they expect to occur a certain way and which does not. Whether this is because it is not implemented correctly or because it is not implemented at all, doesn't matter.

This is compounded if your users or error reports are also engineers, in which case they assume that any feature they want could have been implemented by them in 5 lines of code, regardless of reality.


In my opinion, the original usage is what you expect:

  1. Bug means "it does something wrong"
  2. Feature means "something we'd like it to do it doesn't even try to do yet"

However, there are obvious similarities in that both are things you have to do, and sometimes there's legitimate doubt, and many people make jokes that one is a sort of the other ("it's not a bug, it's a feature, etc.")

Specifically, there's two common, widespread and reasonable ways people use "bug" to include "feature":

  1. When the user has (very reasonable or unreasonable) different expectations to the programmer. The user thinks "wait, I should be able to drag but I can't, it's a bug". The programmer thinks "I haven't implemented dragging yet and there's no UI to suggest you should be able to". (If it's a sufficiently important feature, it's as important as a (non-dangerous) bug, in the sense that "without feature X, people can't use the software".

  2. People commonly (and for lots of sensible reasons) use bug databases to track any sort of change to the system you've decided to make.

If you do maintain separate lists, it's important to be able to migrate items between them, so you can route items the correct place wherever they come in. If you combine them, distinguish between what you HAVE to fix, and what would be really useful, but the code will still work if you defer it to the next release.

When you're deciding what to do next, it's sensible to generally distinguish (eg. fix all the outstanding bugs you're ever going fix first, then new features, or whatever). But not always.

If someone is describing the unfinished features as bugs in the sense that "something's wrong", then they're wrong. If they're describing them as bugs in the sense that "they're something you're going toresolve in the code" then they're right.


Some would try to pass a bug as a yet to be implemented feature.

But HOW you categorize this is dependent on who raised the request/complaint If its the client who raised it expecting a feature already sold to him This would be a bug.

But you state that project is in development .If you have just started development on these Then it cannot be called a bug.

But if you are very late into the project and have barely managed just One feature ,where all the Three features could probably have been completed .The management might chance to view the missing features as bugs.


A feature not yet implemented is an enhancement not a bug.

  • Yes a bug is more of an enchantment... ;-) Mar 15, 2011 at 20:17
  • 1
    But a heisenbug is an enchancement :-)
    – Stephen C
    Mar 16, 2011 at 3:41

Is it fair to refer to a feature that has not yet been coded as a "bug"?

No I don't think it is fair.

If someone said that to me about my code, I'd immediately revise my estimate of their intelligence ... downwards. Then I'd say "Whatever" and move the topic of conversation onto something more important.

Having said that, it could be that your unimplemented features are showing up as failed tests on your nightly builds. If that's the case, see if you can disable the specific tests until your code is ready to be tested.


We call them feature requests and prioritize them appropriately. Pri 1 bugs are must-fix, p2 are nice to fix, and so on.


I would be hesitant to classify a missing, knowingly unimplemented planned and promised feature as a bug.

There is definitely a problem but calling missing features a bug doesn't quite do it justice or communicate the potential severity or urgency; especially if the overall effort or particular phase/iteration is under contract; or the missing feature(s) is part of a marketing campaign. If this is your scenario, I would strongly lean towards pushing release date to a later period, in order to deliver what was promised, even if the missing features are somewhat less than elegantly implemented.

If it is part of a short duration sprint, and releases are regular and frequent, your team might be ok by just pushing it back to the next sprint and demonstrating more consistent planning and delivery going forward.


To oversimplify:

  • a feature (or improvement) is something the customer has to pay for to get it
  • a bug has to be fixed for free.

so for the customer every thing is a bug and for a producer everything is a feature.


When you come to tracking this stuff, you need a place to record defects, and new OR missing features.

The best place is a SINGLE PLACE to record it all with an appropriate system of categorisation.

So you might say that a report is "feature request", "crash", "stops-getting-work-done defect", ..., "textual error" as your means of putting them into sortable, prioritisable groups.

If you have one system it makes it easy to allocate features as well as defect fixes to a build. If you do it any other way its hard to keep the scope in one place that is searchable and can show progress.

Features might be those that are desired and scheduled for a future release. They might also be features that are required for a release and not yet done. You might even choose to ship with some features incomplete or missing.

In this sense, the LACK of a feature does in fact comprise a defect: the function that should be present (by explicit requirement, or by some implicit desire) is not present.

You CAN if you choose go a step further and during initial development place all the requirements or major features [the lumps of your story... all depends on the process you use and the terminology you like] into the defect tracking system as well.

I've done this and it makes working through the feature sets toward completion go really well.

It annoys the heck out of testers who say "how can I track defects when it started with lots... and that dropped as you finished work packets". The answer is: tough... tune your reports better!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.