Have you ever been in the situation when looking at the code you couldn’t tell if something is a bug or poorly implemented feature? Or you simply didn’t dare to fix something that looked like a definite bug to you, but were not sure if anyone already relies on the functionality behaving in a certain way?
What are your best heuristics for telling bugs and features apart? Any good stories?
Easy, If it's not documented on a BRD or TRD, then it's a bug.
Example: I wrote a news editor application for a previous company. It was documented that the application would allow export to RSS 2.0. I figured it wouldn't be difficult to just allow it to export to any RSS version, so i did, including the obscure netscape versions. I received a bug report that it "could be exported to more than documented formats outside the project specifications". And I agree. That was a bug, not a feature. A purposeful bug, but a bug none-the-less. After being in this industry for so long, I understand that you code to specs, and anything that happens that is outside the documented specifications is a bug.
There should be absolutely no confusion. Either a behaviour is documented or it is not.
Change requests for new features or to deprecate old features should be listed in some sort of change control documentation with a dead line as to when it should be implemented. These changes should not be checked for by changes until the documented time. Bottom line, if you maintain good documentation, then this should be an issue.
I've definitely had that happen and have had to go through tons of source code to determine if a mistake was made or not. Sometimes you end up having to make assumptions and then testing it out to see if your assumptions were right.
This is an area where I, as a developer, have always been at odds with the testers. Everything always seems to get classified as a bug, even new features, simply so the new features could be justified into the current release cycle.
A good rule of thumb is: if it causes a loss of data, crashes the system, or results in an otherwise unexpected operation its a bug.
If the requirements clearly state one thing at time of development and the implementation was incorrect, its also a bug.
If new functionality is added as a result of requirement change then its obviously a feature.
If a bug fix requires that a new feature be developed in order to fix a problem then you should probably classify it as a feature.
The place I experience the most push back is when requirements change after given to developers and suddenly "features" become "bugs" because they were implemented incorrectly. This is a problem which can really only be solved through proper requirements and expectations management, something which is often sorely missing in software development (or at least the projects I have been on).
"Have you ever been in the situation". Yes. Basically, this happens whenever you look at a function and aren't sure what it's supposed to do.
"What are your best heuristics". Write tests. Document internal interfaces. Use good names. Comment code (some consider the last of these undesirable or a last resort. I disagree, but if they get by without it then all power to them). On encountering code written by someone who hasn't done those things, find them, torture a confession out of them as to what the code is supposed to do, and get the above things sorted out.
There's a good maxim that you should write code as if the maintenance programmer is a psychopath who knows where you live. Game theory predicts that a threat doesn't work unless there's a non-zero chance of it being carried out. So someone has to be that psychopath. I humbly volunteer.
As an absolute last resort, when you can't tell the intent of the code and you don't have enough tests to prove whether a change is harmful or not, the question comes down to "if I change this line of code, will the program work better or worse?". I'm not really aware of any good heuristics for answering that question, other than:
If you decide it's a bug, you change the code and take a gamble whether you've saved the day, or broken someone else's calling code somewhere. But if the application currently works, then the presumption should be to leave behaviour it as it is, even if you want to improve the specific code. So you may end up simplifying the code in the common case, at the cost of having to add special cases that you aren't sure were ever intended. A null parameter to the current code for convoluted reasons causes IOException rather than NullPointer? OK, keep that behaviour unless you can prove that nobody relies on it. If a better way to write the function is to call some method on that parameter before starting the IO, then you'll need an explicit check-null-and-throw-IOException. Call it backward compatibility.
It depends on whether you are talking about something that occurred during the current development cycle or something you've discovered that has been in production for awhile.
If you notice something in a piece of code you are working on that deviates from specifications then it is easy to label it as a bug and fix it. Or, if there is a gap in the specifications then you can seek clarification from a BA or whoever is manging your specs.
However, if the code has been in production than it's a different story. In my view, the code is the ultimate specification. Spec documents can often become out of date relative to the code and subsequent bug fixes. If the code is doing something, then chances are people out there are relying on that behaviour even if it is a bug. E.g. if you have a method that contains an off-by-one error then there may be customers who take that into account and correct the result themselves.
This is not to say that you can never fix produciton bugs, but the line is more difficult to draw and may require discussion between technology and business groups to decide whether it is necessary to fix. If something is obviously causing a crash or data corruption then it will be a trivial decision but there are many other grey areas.
As much as I hate to say it, I think some of the distinction between bugs and features is not drawn by the developer. Maybe the requirements were clear, maybe the design was clear, maybe the implementation was clear, but if the result is not what the customers want, to them, it's a bug. (I suppose you could say in that case, the bug is in the requirement ... even if the customer signed off on it.)
As others have pointed out, if your system is documented well, you shouldn't have to decide; the documentation will tell you. I have worked on systems that had very poor documentation, and sometimes it was really difficult to tell the difference between "by design" and "by accident", particularly if the "bug" was difficult to reproduce.
Dependency can be a tricky issue. Unless you can demonstrate that current functionality is incorrect (returning the wrong value from a function or something like that), it may be difficult to fix an issue if it is old enough and has spread to enough people (like sk mentions).
I did see a number of situations where no one, including the original programmer, could remember the precise intent of a particular section of code ... it was surprising how often we were able to fix the problem without people complaining. Sometimes, if it seemed to be a usability issue, people not only didn't complain, but immediately praised the changes, almost as if they were hoping we'd fix it but didn't want to bring it up themselves. (Again, this is from a very poorly-documented system.)
The question "is this a bug or a feature" boils down to "should the code do this or not"? That's not a question that a developer should be answering.
In an ideal world all the behaviour should have been locked down in a requirements spec. None of us live in an ideal world, of course; even so, hopefully something has been written down about what the code should do. It it doesn't do that, it's a bug.
Since we aren't in an ideal world there will always be behaviour that is not covered by the requirements spec. Maybe a little, if the spec is good; maybe everything if the spec was never written down. In either case what you need here is someone who can speak for the users, and say what they expect should happen. Sometimes they are called Product Manager, sometimes Product Champion, sometimes User Representitive. Either way, it's their call to say what should and should not happen. They decide if what they see is a bug or a feature.
Obviously it should be possible to negotiate with the PM; the developer might want to say "we do it this way because it's very similar to what happens in this case", or the very persuasive "if we do it any other way it'll cost a month of development time". But it should be their call in the final analysis.
Bug is to feature as weed is to flower.
It's often a subjective call, but it's usually a bug if it detracts from the overall quality of the product. Anything that adds value (value -- not simply functionality) to the right consumer is a feature, though there may be room for improvement.
Bottom line: if it benefits the customer (internal or external), it's probably a feature. But if a reasonable user (QA, product manager, etc.) thinks it's a bug, it probably needs rework or removal.
Check out:
That's Not a Bug, It's a Feature Request
One of my favorite things about UserVoice -- which we use for Stack Overflow -- is the way it intentionally blurs the line between bugs and feature requests. Users never understand the difference anyway, and what's worse, developers tend to use that division as a wedge against users. Nudge things you don't want to do into that "feature request" bucket, and proceed to ignore them forever. Argue strongly and loudly enough that something reported as a "bug" clearly isn't, and you may not have to to do any work to fix it. Stop dividing the world into Bugs and Feature Requests, and both of these project pathologies go away.