Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
9  
Bugs are "undocumented features". –  S.Lott Mar 15 '11 at 15:47

16 Answers 16

up vote 9 down vote accepted

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.

share|improve this answer
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 '11 at 16:31

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.

share|improve this answer

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.

share|improve this answer
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. –  Berin Loritsch Mar 15 '11 at 16:31
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. –  Berin Loritsch Mar 16 '11 at 12:13

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.

share|improve this answer

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...)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
1  
But a heisenbug is an enchancement :-) –  Stephen C Mar 16 '11 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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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