SimplyGed nails it above - most of the time the difference between a feature and a bug is whether it’s in the requirements. Is it an absolutely necessary feature that was overlooked during the requirements gathering? Then it’s a bug in the requirements; fix them, then revisit your feature/bug decision.
The difference for many of us in the industry is that we tend to get paid for features, not so much for bug fixes. So feature vs. bug becomes a very important distinction.
Does that give us incentive to nudge things into the features bucket? It would, if we were jerks. But we have ethics as a check on that incentive.
I must be psychically channeling this blog, I was just thinking about this when I went to reply in Mail on my Mac a minute ago.
When you reply to a message in Mail, the first time, instead of putting the old message in the reply text below, it puts the clipboard contents, and that’s it. I had copied some text from that message for use elsewhere. But when my reply window opened my first response was That’s not right! So I closed it, and retried and got a normal looking reply.
At first I was like man, that is a weird bug. But really it’s a good example of a strange feature. Someone my find that useful, just not me.
Really any bug or problem does not exists in some holy place of truth, they are personal judgement calls. Nothing needs to be fixed unless someone first says it is broken. I sound like a beauracrat here, where the opposite approach would be true: we’ve always done it that was, so why change?
Jeff… how can you make people choose between Coke and Pepsi? that’s not a (fair) choice! I’m not a fan of both, but Pepsi isn’t cola, it’s some kind of adult lemonade…
@Joe: You just take the whole pile of things to do and sort them by priority.
I guess your question is based on a distinction you are making between the program was not supposed to do that (a bug) and the program was supposed to do that, but it sucks (a feature request). You just need to start treating both kinds of items as: this behavior needs to be changed
Funny you should mention this now. It was just yesterday that I started an open source project and decided to lump the bugs and feature requests trackers into one, for the very reason you mention.
Runaway Moon Docs, it’s more pronounced on LCD monitors, but Microsoft Sans Serif is a lot blurrier and thicker. That’s not so much an issue if everything is running Sans Serif – it works, if not perfectly, and users are nothing if willing to adjust – but if there are a lot of applications running at once, the difference is jarring.
I kinda find it frustrating that VisStudio doesn’t just default to the local OS’s default font.
How do you control the scope of a project if you don’t classify requests into bug fixes and features?
Joe, I find it more important to have priorities than sections. Just because something is a feature request does not automatically make it less important. A feature request that would provide even mediocre benefits for the main feature can be vital, while a bug fix that’s only affecting a very small group of people or is easy to work around seldom makes or breaks an otherwise decent application.
There’s no difference between a bug and a feature request from the user’s perspective
Sure there is. If you clearly state prior to any development commencing, that a bug is a user experience that wasnt outlined in the requirements of the system and agreed to and signed off on prior to development AND a feature is something ELSE that they want added (or even taken away) from the agreed to/signed off features of the software application.
I do not begin development on any application until a full and clear understanding of what a bug is and what a feature is and a sign-off on what the definition of scope-creep is. Nothing and I mean NOTHING can or will be added once development has begun.
This is something I learned from decades of software development and also noting how other professionals handle similar projects. Dont ask a builder to add on a sunroom or enlarge the kitchen during the building of a house. Oh, they may do it if you force them to but they’ll rip down your 1/2 built home and start over AND/OR they will ask for a significant amount of money.
Bugs are bugs. They are experiences that are not ever supposed to happen. Crashes, definitely. The application doesnt store a business phone number? Well, if it wasnt asked for then its not a bug. We’ll added it after the application is done and for an additional cost.
This forces both the user and the developer to do heavy due-diligence and to extend the analysis and design phase of development.
I think this is not a bug but a feature request. It becomes a bug with withful thinking. So Microsoft is right when re-classified from bug to feature request. It could be a bug when in form editor you specified Tahoma font and in reality got somehting else when your app was running. But it clearly delivers what you see in editor.
But yes, here problem is that it does not default to system default font. That is feature request and very valid. Seems CodeGear has managed to cure this problem with recent Delphi incarnations, it also defaulted to MS Sans Serif for all new forms previously and there were no means to automatically switch to system default font.
I agree that developers do sometimes use the feature request distinction against users, but I think that’s at least partly due to the fact that some managers and other higher ups like to use bug counts and bug fix rates as metrics of project health and success.
So we end up gaming the system ultimately, forcing certain user feedback into the feature request bucket to make our bug counts look good.
Of course, (as other folks have already pointed out) having reported bugs doesn’t neccessarily mean that the software sucks, but it DOES mean people are using the software. As a developer, I absolutely love pushing out releases that address bugs whether they be usability enhancements or fixing a true crash and burn error and I wish I was given more time to do that on some of the software that I’ve built.
I consider a bug to be some kind of unexpected behavior, such as an error message or improper display or incorect calculation of some field or something just plain not working as intended.
A feature request would then be some new kind of functionality that wasn’t in the app previosly.
For example, if a user wanted to sort on column A and sorting was setup but it got an error when they tried or didn’t sort dates correctly, this would be a bug. But if sorting were never setup, this would be a feature request.
… so I guess TRWTF (to borrow from another website) is that you’re working with Joel and NOT using FogBugz. I have to assume Joel is working on an equivalent add-on!
It’s a bug if it conflicts with a stated requirement or causes the system to crash.
It’s a feature request if it wasn’t specified, was poorly specified, or the user just wants it differently.
Which is why I like Agile - everything’s just a change and you no longer feel bad. The user accepted it at one point of time and the fact that they now want it to work differently is A-OK with me.
change:
severity - how much of the system is affected
priority - how badly does the client want it changed
requirement conflict - Y/N : Req # (really just for reference)
Being inflexible never helps. People always want things to work well for them, and refusing to fix anything not in a requirements document is just hiding behind bureaucracy. Sorry sir, I don’t care, it’s not in the requirements.
You’ve also got to be careful when you use metrics and people end up gaming the system. QA is paid to find bugs, and they’ll find bugs where they never existed and pretend they’re all priority 11 (aka Sun is about to go supernova).
But I digress. Agile is intense but less stressful because you work with the client, not against them. The client sets priorities and they’re the one that tells you when they’re ready to release and not the other way around. Sure you still write documents and other stuff, but you’re not chained to the document. It’s not a list of commandments from the almighty ${diety}
FWIW Uservoice is fine, but on more than 1 occasion I’ve seen the hand of the almighty speak : ‘Its not a bug, there’s a workaround’. So maybe you’ll think twice about the users voice (or lack of one) and not shut down requests before people have time to vote on them. If I took the time to report the bug, it probably shouldn’t be dismissed out of hand.
I think the real question for most projects is, Do we plan put this change into a point release or the next major release? For a web app like Stack Overflow, I’m not sure that’s meaningful, since you can do all development incrementally. I’d imagine you still want stabilization periods, though.
However, I think I did define bug fairly well here:
There must be somewhere a MS Visual Studio 2008 design document somewhere. If it says that the default font should be MS Sans Serif whatever, then we would be talking about a feature request. If it says use the system default then it would be a bug.
Also, keep in mind that the term default font itself has to be properly defined. I can set the default font of my system to (grasp) Comic Sans if I want to (as opposed to the font that the OS comes with on the first boot, by default).
A bug is when the code doesn’t do what you designed it to do.
A feature request is when the design doesn’t do what the user (or other stakeholder) wanted it to do.
In the end, both need to get fixed. The distinction is useful in prioritizing, and measure how well we planned and how well we executed against our plans.
Feature requests are also learning opportunities. A bug report from a customer is useful, but it doesn’t tell you much about what your customers want. Feature requests give you insight into what your customers want.
So Microsoft is right when re-classified from bug to feature request. It could be a bug when in form editor you specified Tahoma font and in reality got somehting else when your app was running. But it clearly delivers what you see in editor.