For as long as I've been a software developer and used bug tracking systems, we have struggled with the same fundamental problem in every single project we've worked on: how do you tell bugs from feature requests?
This idea of there being no Bugs vs. Features distinction in the user’s mind is certainly one that is valid. However, what if your software is being written in the context of a contract with a fixed budget?
This distinction becomes very, very important. It’s all about who has to pay for it. Bugfixes generally happen on the contractor’s dime, whereas new features generally require the client to fork over some extra cash. It’s a distinction that is far too consequential to ignore.
It’s also consequential within the context of the internal development process. Have you ever worked for a lousy project manager who can’t write requirements and specifications? I can’t tell you how many times I’ve been inundated with bugs where the project manager incorrectly articulated her intent. When the project is over-budget and the axe starts swinging, you need to be able to make the case that My PM gave me a last-minute feature request and called it a ‘bug’ so that A) it has to be done before it goes out the door, and B) the blame can be shifted to me. (I realize that this represents an awful working environment, but sometimes we find ourselves there.)
UserVoice also blurs the line between system components (by not providing a way of tagging issues by component). It blurs the line between visual glitches and behavioral issues by failing to provide any facility for attaching screenshots. And it blurs the line between brief comments and detailed reports by failing to support the latter.
You don’t need UV to blur these lines. We had a bug tracking system written in Excel back in '99 that blurred lines by being a crappy bug tracking system. If your developers are looking for excuses to ignore user requests THEN THAT’S THE PROBLEM, not the feature-rich bug-tracker that enables them. Laziness doesn’t need enabling; laziness always finds a way…
The five boxing wizards jump quickly
The five boxing wizards jump quickly
Oh yeah… Worlds of difference here…
Well, I guess they’ll fix it now … 
(Font bug in VS)
.t
The differences in the typeface I admit are minimal (to me). In the first, the S character appears stretched and ugly. The whole sentence is a little stretched out also.
I suspect this is what Jeff means by design is very subjective. I’ll be the first to put my hand up and say I can not do visual design. But then again, I’m not a visual designer, I’m a coder.
Designers take a bunch of these little design characteristics and make them better. It’s their job. A bunch of little improvements pay off at the end. One micro-optimisation is hardly going to improve the UI dramatically.
Think about it in terms of a well designed algorithm. Your users probably won’t notice a 20ms increase in performance. However, they’ll probably notice 50 individual 20ms increases in performance.
On another note, I’ve just signed up to use fogbugz and find it pretty cool though my experience with bug tracking is minimal. Not sure if you can filter by bug/feature easily but I’ll be looking for it right now.
Ah, specs. What happens when the people who authored, approved, or signed-off on the specs are executives and managers - not the people who actually have to use the software to get a job done? Then the bug/feature list (which presumably comes from people actually trying to work with the software) turns into a ‘secret battlefield’ where ugly heroic measures are attempted to prevent the project as a whole from going down in flames.
Well I had a big long tirade written, but Jason summed up my thoughts more eloquently and in about half the space. The bottom line is that the difference is who pays for what.
Of course the contractor would like to push everything into the ‘feature request’ pile and the client would like to push everything into the ‘bug fix’ pile. Yes, some of these ‘issues’ clearly belong in one pile or the other, but there always ends up being a number of them which could be either depending on who you ask.
The answer is not always as cut and dry as some of you seem to believe.
What atrocious hypocrisy! This from a guy who can’t be bothered to track his own feature requests properly, nor provide adequate explanations when he declines such a request.
Microsoft is a massive organisation, and while in an ideal world, they’d all follow the same conventions perfectly, in reality, it’s just not going to happen - different departments, different teams, all working to get their core objectives fulfilled. You’ve got a small team, and yet there are some appalling inconsistencies and bugs in your web site.
There are numerous examples of Microsofties who do strive to maintain consistency in the user experience, but fixing major security flaws is always going to take priority over smaller fixes. Finally, you probably shouldn’t be so quick to judge what’s easy to fix and what’s not - plenty of straightforward fixes actually require a lot of investment in time, and multiple developers/testers/translators/documentation writers involved, especially in companies that actually give a shit about writing a decent product.
I don’t see why there’s such a gray area.
If the user wants something to work a certain way, and that way is the same as what is described in the requirements document, then it would be a bug if the application doesn’t work that way.
If what the user wants isn’t in the requirements document, or what they want is different to what is described in the requirements document, it’s a feature request (or change request).
I don’t see the ambiguity at all. That’s of course assuming that you have a solid requirements document that is specific rather than vague.
The confusion between bug / feature request is just a requirements definition problem, nothing more. It’s only confusing if your requirements are confusing, and in that case, you have more urgent problems than deciding which classification a piece of functionality gets.
@David Avraamides
You are just punting on the problem. You are assuming there weren’t bugs/missing features in the requirements/specification to begin with. Maybe the bug was that it should have been in the requirements doc but someone missed it so now you are categorizing what should be a bug as a feature request (and probably treating it differently).
The requirements document is, at least in my experience, signed off by the customer before development work commences.
The requirements document is a contract which specifies the work which is to be completed. If a feature the customer wants is not in the document, it’s not a bug at all.
The customer signed a contract stating that this is what they want. They know want something additional to what is stipulated in the contract. Thus, it is a new feature.
I realise this is what Jeff was refering to when he was talking about using it as a wedge against customers. In reality, our development team is never this rigid, at least at the start. We do make a lot of allowances for these omissions, because it is impossible to define requirements 100% correctly. So I want to stress that I don’t think this wedge is a good thing - and we don’t follow the letter of the law. We give concessions on small features and on additional work, particularly if that area of work hasn’t begun yet.
However, there’s a point in time where you have to draw the line - you’ve made plenty of conessions but future changes are going to impact the deadline and they’re getting more costly to make. Now you have to wield the requirements document as the contract that it is.
There are obvious reasons: so you don’t get taken advantage of with an endless stream of free features, and so the customer can decide what they really want (people are generally much more picky about what they want when they have to fork over cash for it).
It’s the natural progression of the software development process. The classification between feature request and bug is straight forward and absolutely necessary, unless of course you’re happy to continue adding features and making changes indefinitely for free.
I’ve noticed that Microsoft in general tends to not correctly follow their own GUI design rules, so I’m not surprised that Visual Studio doesn’t properly implement them in its form designer.
What, you expected the Visual Studio team to read the Microsoft GUI design guidelines? Heck, the Office team certainly doesn’t!
P.S. Why is this post dated yesterday’s date? I know it wasn’t here yesterday.
Bugs and feature requests, I hate them both, but if you’re not doing one or the other then your software isn’t really being used.
In my workd feature requests are called enhancements. Our ERP vendor calls everything that doesn’t crash and burn an enhancement and then suggest you contract with them to customize the product.
A few years later they use the customized code, that you paid them to create, to fix their base product. Therefore, the customers are trained to wait years for this ERP system to enhance their product.
In addition to what you stated above (broken vs. not broken), surely it depends on the requirements (you do use requirements, don’t you?)
If it was in the requirements/specification and not implemented (correctly) in the software, then it can be defined as a bug.
If it wasn’t in the original requirements/specification, then it is a feature request.
This is why on the web we actually have people who are designers. Pure programmers are notoriously bad at design.
Personally, I can make your interface really easy to use, but I can’t make it look good. Believe me, I have tried, and I can’t tell the difference. I have had many moments where people show me before design and after design and they look the same to me.
When you say it is an insoluble problem you mean like in NP-hard? XD
(Sorry, couldn’t#12288;resist.)
Amen!
And this particular bug in VS drives me batty. Why can’t we at least set the default font in a config setting? I can’t tell you how many times I’ve had to click on a form and set the font to Tahoma or something more suited to the OS at hand. Just let me do this once on some options dialog and be done with it.
You are so lame dude. For real.
Get a life. Stop thinking your a programmer when you’re a lamer.
reminds me of:
http://globalnerdy.com/wordpress/wp-content/uploads/2007/12/bug_vs_feature.gif
we keep a printed copy where i work. a feature request is normally a dressed up bug.
