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

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

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?"

How do you control the scope of a project if you don't classify requests into bug fixes and features?

Simple solution: if in doubt, it's a bug.

>Here's a comparison of a label with the default font, versus one that was explicitly set to the default GUI font.

*fails to see the difference*

Its because Microsoft doesn't give a shit about its operating system UI consistency.

Spend about 30 minutes in XCodes interface builder and get ready to cum your pants

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

Oh, and the rest of your post was obvious :p

@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"

Hah, this post made me giggle, nice job!

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.

I also don't see much difference between those two fonts, but typography doesn't really interest me.

"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 always saw a clear distinction in the two...

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!

The feature is specified in your tests, the bug is not.

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:

http://www.codesimplicity.com/archives/36

That definition has worked fine for me ever since I first wrote it (long before that blog post).

The only type of change that I left out, there, is a refactoring, where you change code but the user experience remains identical.

-Max

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.

Unfortunately, the distinction between bug and feature request is very important when it comes to if work on the issue in question is billable to the client or not. In a lot of cases fixing bugs is not billable after release.

There is a difference between a bug and a feature.

A feature is when a user wants something different; a bug is when he wants what you claim to provide, but don't.

There usually is a business need to distinguish between them, because you have to fix bugs from free in many cases, while you can make users pay for (or wait for) features.

Anyone who thinks otherwise is not working on software used by companies.

I love how people cling to requirements as their defining line between bugs and feature requests. Lets face it folks, requirements are hardly worth the electrons it takes to display them on your screen. I don't care if the requirement covers every possible interpretation and the customer signed off in blood - as soon as the app is realized and in front of my face, if I don't like it, you should fix it. Prioritize, complain and moan, ask for more money, whatever. The job of software is to make the user's life easier. If it's making it harder, the software needs to be fixed. It's all semantics, the software doesn't live up to the user's expectations - call it a disenchantment if that makes it gets the darn thing addressed.

I like James McKay: "if in doubt, it's a bug". Much easier.

What you're saying makes sense if you're working for the company that you're designing software for. If you're a custom software development shop, then it's a different situation, and gets back to "do you charge for fixing bugs"?

Microsoft's DevDiv has a real problem with dealing with bugs that are actual bugs, so a feature request going uncommented for four years is hardly surprising.

I'd say that not disposing of non-graphical controls dragged onto a form was a bug, wouldn't you? Apparently Microsoft don't think so: *still* no feedback from MS on my bug at http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=305534.

@SteveJ: "requirements are hardly worth the electrons it takes to display them on your screen" - Great!

Requirements in a formal sense are conspicuously and characteristically absent from nearly all open source projects, so the distinction isn't really so well-defined in that environment.

Robert Lefkowitz has some interesting things to say about that: http://oscon.blip.tv/file/1108217/

P.S. -- That behavior in Apple Mail is also present in Claws where simply highlighting a section of a message before hitting reply serves to automatically trim the quote to just the higlighted portion.

Maybe Apple added that feature to apologize for the default behavior of setting the user up to compose a top-posted reply, which I personally file under "bug", not "feature" :)

The application shouldn't choose a typeface. it should get it's typeface from the window manager. This is one of the things I HATE about windows. Applications don't let you tell them what typefaces to use, they use what they use, and to hell with what the user thinks looks good.

So this is a feature request, because to fix it requires fixing the window manager in windows, and fixing every single app in windows, because they are ALL broken in this way.

To me, the distinction between bug and enhancement is easy. Of course, I am a developer, so I know how these things work. A bug is something that works contrary to the design of the system (crash, 2 + 2 = shoe).

I agree that general users often aren't of the same mindset. There are multiple reasons for this. One reason is that users are often not even aware of specs, so they go by what they're used to.

Basically, to many users, a bug is when the system works contrary to how they *expect* it to work.

In some cases, though, it really does make sense to strictly classify these. Company X pays you to create a program for them. They give you specs, and you give them the finished program. You are still liable to fix bugs (not working as designed). Enhancements or new features would likely be grounds for a new contract, though.

I think there is a faulty assumption that removing the "bug/feature" attribute of a request would have made the "Visual studio doesn't use the correct font when building Windows applications" issue get addressed any faster.

If the vendor doesn't want to address it, they aren't going to address it. Period.

LOL. We used to call bugs "random features".

Seriously, agree with Charles. If the vendor doesn't want to address it, they won't. And they might not want to if (a) it isn't a security risk and (b) enough high profile customers aren't complaining about it.

While I enjoy the irony of Microsoft violating its own standards, I think the gnome-screensaver more than makes up for it in the open source world. http://bugzilla.gnome.org/show_bug.cgi?id=316654 The ability to choose your settings is an important part of a screensaver application, and yet when gnome-screensaver is missing it, it is a feature request which is somehow... evil. This is an excellent example of the fuzziness being used against the user.

So, we're assuming here that Visual Studio should default to the system font for whatever OS you are running it on?

Would that really be a good default? One of the features of Visual Studio is that you can build applications that target different versions of Windows, mobile devices, etc...

Perhaps it should default to a setting that says - "use the default font based on the OS context". Still - most people probably want to have a little more control than that.

I think a lot of bug / feature requests don't get implemented because it is unclear how something should work. If you do it one way, you're going to annoy 25% of your customers -- if you do it the other way, you're going to alienate another 25%.

I disagree that bugs and feature requests are the same thing though. If you take that point too broadly, you could say that there is a bug in Microsoft Word because it can't edit your home movies.

Software has to have a point -- a focus. It can't be all things to all people. Otherwise, we would just have a single program that did everything.

Who cares which it is? I have a different system. We log everything to a central place, with no distinction between the two. I then let the users choose the priority of their requests (in relation to each other) and the top ones get fixed first. No need to care. Even if it is a bug, but the feature request is more important to them, we do that first.

> Software has to have a point -- a focus. It can't be all things to all people. Otherwise, we would just have a single program that did everything.

Emacs!

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

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

I agree with Jeff's general point that the distinction between a bug and a feature doesn't really add a lot of value to the development process. I think more about the impact that the issue has: does it keep the user from doing something that the program _should_ do? Which comes back to Timothy Lee Russell's point that a program should have a focus.

the distinction is clear... bugs I fix for free, features I charge for :)

One of my favourite games! Feature or creature...

http://nomagichere.blogspot.com/2007/09/feature-or-creature.html
http://nomagichere.blogspot.com/2008/02/time-keeps-on-slippin-slippin-slippin.html

Your definition of bugs or enhancements depends greatly on your level of agility.
http://agilemanifesto.org/

@Adam - Perfect!

It's always a feature for software vendor because they can always charge for it.

It's a bug for the customer because they don't have to pay for it. The vendor should've known/asked better.

Try to set a different font in Vista, reboot (you never know if it will help or not) and then look at how many fonts are unchanged, ie are the 'default' Vista font. This bugs me, a lot.

The idea of using the "default system font" is also not really workable. The default system font on XP is different than it is on Win 2000 and also Vista. And I might be creating apps on Vista that I will also want to run on XP.

So the better solution is to just let me choose or to define a font named "system" that I can select for my forms so that the actual font used is chosen at runtime. But it is hard to make a designer do this.

Personally, I prefer the option of giving users the option to choose through configuration. As far as I know there is no way to choose which font the forms designer uses by default. And to me this is wrong. It's not a bug. But it's not right either.

When comes to bugs/defects and feature requests there can be a way to detect. This is obviously expecting a bit from the project or company. But if the project has good requirements/expectations of what the finished product is going to be it makes the process easier. Then in your QA or review of items submitted you use those requirements. If it is going away from the direction of the requirements it is a feature request. If it directly relates to a item associated with your product direction then it is a bug or defect.

Bottom line you have to research the entry, and you need documents to research against. Otherwise your right you can't make a clear distinction. Then if what is reported is a "showstopper" you obviously need to take care of it immediately. But do it towards the direction of your requirements and or product vision! :)

The biggest problem when dealing with a definition of a bug versus an enhancement (or a design omission) is perception. If you coded a program to do one thing, and all of the users start using it for something it wasn't quite intended to do, is it your responsibility to 'fix' it to do that thing? No. It's not a bug, but if 98% of your user base is using your screwdriver as a hammer, chances are, you're going to make one section flatter and heavier and add a handle and call it screwdriver 2.0. :)

I hacked my VB6 to use Segoe UI by default. Anything that doesn't explicitly have a font set is now no longer MS Sans Serif.

I don't like Vista that much, but the fonts are nice...

> Party like it's 1996, folks, because you'll get MS Sans Serif, and you'll like it.

If you actually used "MS" Sans Serif, the bitmap font, at any size above 12 point, it *would* look like crap. Fortunately, your Properties Pane shows that you're using "Microsoft" Sans Serif, the OpenType font, which really doesn't look bad at all. All things being equal, bitmap fonts are usually going to look worse than OpenType fonts.

That being said, was there *ever* a time when VS.NET didn't do this?

I suspect the problem is twofold.

Firstly, Microsoft tried to do the seemingly logical thing but developers abused it. In an ideal world, GetStockObject(SYSTEM_FONT) would return you whatever font was the default for the system. However everybody and thier dog wrote their app assuming that the entire world had the same system font they did, and when it wasn't their app didn't draw correctly. Microsoft then tried to address this by creating DEFAULT_GUI_FONT, which was promptly abused in the same way. These sort of abstract definitions always end up getting stuck forever because of app compatibility.

Secondly, this is the 21st century now and we all have hundreds of fonts installed. There is no such thing as "the" system font. Windows is perfectly happy to set *different* fonts for captions, menus, dialogs, status bars, command prompts, etc, etc. Which of these is "the" system font?

IMHO the guideline about hardcoding Segoe UI is just as busted as using SYSTEM_FONT. The next time Microsoft gives it's UI designers some slack they'll go changing all the defaults again and we'll have to have another round of "why are these lame apps using (System|Microsoft Sans Serif|Tahoma|Segoe UI) instead of (New Hotness)?"

Wow, way to sell all of us up the river, Jeff. "These poor pitiful users, why should they ever have to suffer the pains and arrows of an application that doesn't work exactly the way they'd like, but never bothered telling their developers?"

The difference between bugs and new features is clear: if it was in the spec or could be reasonably implied by the spec, but isn't in the application, it's a bug. Say, for example, you write a search page for your site that delivers hits in order of relevance. After a few days of using it, the users decide that it would be better to sort the results by date. Is this a bug? Under the logic of "you want to do something with an application (or website) ... [is no] different than not being able to do something due to an error message" means, that, yes, this is a bug. Don't mind the fact that nearly all search engines nearly sort by relevance, or that the user never thought of (let alone requested) a date sort in the first place. It's a freakin bug, so fix it free, let your business owners yell at you and complain to their managers about how inadequate the IT department is. Take your lumps like a man, dammit.

BTW, the Visual Studio font issue is clearly a bug because it doesn't follow it's own documented standards. If those standards didn't exist, it would be a feature request. Anything that starts with "It would be nice if" and can't be tied back to some type of document is a feature request, period.

Division between bug and feature request is just a crude way of triaging user demands. Such triaging is absolutely necessary, unless you want to have zero control over how you work. I think that we'd remove this distinction and then quietly introduce another one, like "Important requests" and "Less important requests". What's the point?

Microsoft has the strangest approach to bugs I've seen. User reports that never result in a bug being on the official bug list? Common. Bugs being on the official list for multiple releases without fixes? Not as rare as it should be. Both phenomena occurring at the same company? Microsoft.

Two things:

(1) "There's no difference between a bug and a feature request from the user's perspective?" That's just condescending. When it comes to cars, I'm about as naive a user as could be, but even *I* know that...
- If I wish that my car seats were warm as soon as I got in the car in winter, I'm wishing that my car had the "heated seats" FEATURE.
- If my car doesn't slow down at the bottom of the hill when I press the brake pedal, there's a BUG in the braking system.

I credit my customers with a similar level of discernment.

(2) You chose a poor example. Your overall point ("Microsoft slow to change!") may be valid, but I can't blame Microsoft for leaving the default font to be one that actually EXISTS on 78% of Windows machines.

The way these posts are written, they sound like Jeff's stream of consciousness rather than an organized article with a point. See that over half the article is irrelevant to the topic, which presumably is how to distinguish a bug from a feature request. The only relevant text is the first 3 paragraphs and the last paragraph. The article ironically suddenly concludes that the whole article has been a waste of time and that we should spend more time on actually doing things.

As many have stated, bugs are when something doesn't work according to spec, which doesn't necessarily mean a crash. Feature requests are for the system to do something new or different, with no implication that the system was "wrong", i.e. not working according to spec.

Jeff defended himself in an earlier post that when he writes he usually argues strongly for a weakly held (by him) opinion. In effect, he's just writing his knee-jerk reaction to whatever happens to come to mind and let the commenters do the thinking and writing of thoughtful ideas for him.

@Bob G.:

What about: "When temperatures are below -X degrees celsius, the engine won't start"?

This is a common problem in Alaska and the Canadian Territories (north of the Provinces). You need to hook up a heater to make the engine warmer before you can start it. I can't remember why -- maybe the gas freezes or just gets too viscuous, maybe the exothermic reaction becomes unsustainable, maybe the metals get too tight together and cause friction, whatever.

Is that a bug (engine won't start in commonly-encountered conditions) or a feature request (engine that can operate at very low temperatures, perhaps by heating itself)?

This is interesting. When reading the responses, I'm trying to guess where the poster is in the spectrum from a short-term contract programmer to a developer in a software that is continuously being maintained or enhanced. I think I can guess who is who, but I guess I'll never be sure. :-)

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

Well I AM a contractor. And I'm more then happy as such. And the reason that I need to have a clear distinction is to handle my budget. A BUG is something that is my fault and might come out of my original estimated budget. A FEATURE REQUEST is something new that the customer (or their users) want that wasn't in the original contract. There is a very important need for a clear distinction. Perhaps the feature should have been in there in the first place, but the money discussed did not include that. If the customer wants that build . . well it will cost them. If they want something fixed, well that's on my head.

Of course that introduces the common practice of my trying to push everything reasonable into the feature request pile, and the client attempting to shovel everything into the bug pile.

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.

You are so lame dude. For real.

Get a life. Stop thinking your a programmer when you're a lamer.

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.

VB6 - FontWiz: The Missing Piece in Styling Your Programs
http://www.vbforums.com/showthread.php?t=543037

Adapt to the system font at runtime with minimal program changes.

Note the lack of interest: only 20 downloads in 5 weeks as I write this.

sorry to say, Da Bob, VB6 isn't exactly state of the art at this point.

i haven't read all the comments so i'm sure it's been said before. the problem you have is if you have a deadline and you want to ship a bug free program. you will have to prioritize and i guess the bug vs feature request is used as a way to do that sometimes.

on the other hand, i completely agree. there should be no distinction, there should only be a way to put a priority on anything that is requested. and you should definitely not tell your users that they're wrong for entering a bug by reclassifying it as a feature request. they're essentially doing your job.

If it violates your specs, it's a bug. Otherwise it's a feature request.

You do have specs, right?

This is how IBM did it back when I was a customer of theirs. Worked pretty well.

You know, call me silly, but I can't decide which of the two font examples you posted in the form image are supposed to look like a male donkey. I find both of them to be perfectly readable on my low-resolution laptop monitor, and if I understand your example correctly I think the "Microsoft Sans Serif" font (that's the one on top, right?) looks better and is easier for me to read. That's largely do to me being partial to wide fonts though, I never liked reading narrow print, but the difference is subtle anyway.

So I guess you're absolutely right, its a complete matter of taste. You are correct that the application should default to the system font, but really that's only important if the user changes their system font to something they can read better. I'm pretty certain that 75% of Vista users don't even know that they can change their system font in the first place... Even if they do (I do) the system font is chosen to be readable, so there's not really a need to change it unless you just can't stand it for some reason.

I'm ranting a bit here on how I disagree, but then again I don't particularly agree with a lot of Microsoft's design guidelines, which brings up that matter of taste again.

Great article as always :)

Interesting. Basically, we should simply keep the users happy, no matter if it's a bug or a feature.
But perhaps this division doesn't come because of developers not wanting to write more code. Perhaps it comes also because the users should pay for new features, while bugs are "free of charge". Am I off?

Regarding the article: the Visual Studio forms designer shows the lowest common denominator font that is guaranteed to be present on all systems that can be targeted by a Windows Forms application.

The real issue is the fact that WinForms does not have a mechanism for automatic runtime discovery of the appropriate system font. That's why you need to explicitly specify a font in the first place, and that's why the VS designer cannot substitute Tahoma or whatever -- you don't know if this font will be present on the target system.

This was fixed in the Windows Presentation Foundation, by the way. Since WinForms is obsolete (and the article Jeff linked to is from 2005) I don't expect Microsoft to do anything about this issue now.

All of you who claim it's a BIG difference between bugs and feature requests are thinking like developers. I beleave there probably should be at leas one more category between bug and feature request:
"unintuitive behaveour" or similar. Most users don't know the spec and even if they do, a developer will understand the spec differently than a user. If the software behaves as we geeky developers expect, but the user don't, like 2 is sorted after 10 (because obviously you should have written 02) it's not a bug (the spec sais sort, it does sort by ascii order), neither is it a feature request (you claim it's sorting but it doesn't do it correctly), it's unintutive. (You can probably find better examples)

The big problem is that if you just ignore this category you end up creating a pool of users who has learned the quirks of the system, and later if you actually fix the problem the new users will be happy and the older users will be confused.

Well, the last time I encountered Visual Studio (and I admit it was a while ago), dialog building involved dragging boxes around and placing labels and widget at PIXEL POSITIONS within that area.
I investigated the code built behind it, and saw that things were being placed at absolute x,y locations. ...Which can and will work, and can be made to balance visually - if - like a designer - you have control of the font and kerning used. So hard-coding the font will at least produce the predictable, desired result.

But if it were possible or common for arbitrary, differently dimensioned fonts to be placed into these fixed-dimensioned boxes ... alongside other fixed-position widgets, then UIs would look BAD more often than they look acceptable. Hard-coding the font is a simple protection against surprises for drag & drop programmers who construct their interfaces without the knowledge/ability to check the code and adjust it for proportional scaling issues.

Just like saving a GIF picture of text is protection against a web 'designer' who doesn't know to revisit the code and adjust CSS.

I know that portable, scalable, aesthetic results CAN be achieved in V.S. by using the tools properly - but it requires extra effort. Effort beyond what the default UI gives you.

Anyway, isn't system font SIZE part of the system font settings? Shouldn't THAT be inherited also? Would it be fair to many Visual Studio 'designers' to ask them to make all their UIs balance aesthetically at all possible variations a users customizations may apply?

(I'm a web guy, often working for government agencies - so I DO exactly that - but I wouldn't curse that requirement on anyone who can avoid it)

Good point Qvasi.
I think 'unintuative' (meaning "doesn't exactly match my personal mind-map") is a valid category. And your sorting example is perfect also.
We will sort
backup-02-01-2007.tgz
backup-01-02-2009.tgz
differently depending on different assumptions.

A difference is whether a coder will capitulate and do it the way newly-described 'desired' way easily - or call it an 'extra'.
Which is why, as a work-for-hire guy I build a lot of wiggle room into my estimates these days. Sometimes it's easier to give in than to educate people on useful naming schemes. Other times I try to inform...

NASA is actually quite clear about what's a bug, and what's a feature, which is a relief when you're the one going through documentation.

A bug is something that, according to the baseline documentation, was implemented incorrectly or anything that causes the system to fail. Anything else is a feature request.

Of course, they have the money and we have the code movers, so feature requests don't tend to languish quietly, unless it's one that costs more money than it'll ever return.

is there really a difference between MS Sans Serif and Segoe UI at size 8.25 in ClearType? Sure one or two pixels are different, but not so you could name the font. If you used OS X's font rendering there would be a difference :) I don't like Segoe anyway.

Bug or feature? Sure some users can't tell the difference, but if you have a featureset you can at least explain, that there are things the app is designed to do. If it doesn't do what you said it would: bug. If it's something it should do in the future: feature request.

Oh, and Aero Glass shouldn't be used. I like translucency as much as the next OS X user who can see through dialog sheets, but Aero glass does it soooo badly. ugh.

The difference should stay in the requirements ?
The problem stay very often in the "implicit" requirements !!!

Developer : I've done what's written in the *** specifications document (say feature A).
User : Yes, but you forgot feature B. If you do A, you have to do B. That's how it works !
Developer : Perhaps, but you didn't tell that to us !!
User : You didn't ask us !!!
Developer : It's no written, it's not there !!!!

And so on ...

Conclusion : some (lot of) features are obvious (implicit) for the users in they every day job. They don't mention them. Who's wrong ? The user not telling it or the analyst not asking for ?

And so on ...

For Microsoft it's different. Analysts and developers don't live on the same planet !!! (joking ... :-)

Bug = Fix for free
Feature = Maybee in next release or pay for it to happend now.

Interesting split.

Those who code in the grown-up world of professional paid software development know a feature request and a bug are different things.

Those who don't...well...don't.

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

Oh, we're taking the gloves off, are we? :)

> you've got a small team, and yet there are some appalling inconsistencies and bugs in your web site.

Have you voted up those "appalling inconsistencies and bugs" on http://stackoverflow.uservoice.com ? Because we do fix the top (n) rated items, whatever they happen to be.

If voting isn't sufficient, I heard bribery can be quite effective.. you didn't hear that from me, of course!

wrong questions asked result in wrong answers.

it would not be a feature but an improvement.

I've always liked "Waltz, bad nymph, for quick jigs vex" for a holalphabetic sentence.

Couldn't agree more. Sometimes, bugs really are bugs. And sometimes, feature requests really are requests for new features. But normally, there's a big grey area in between - and the rub is that they typically get treated differently by development processes. When something's implemented that way "because that's the way it was designed", that doesn't automatically make it a request for a feature (i.e. a design change) - that may mean the design was wrong. That makes it a bug.

I wrote about this a few years back, in particular tracking bugs and feature requests as equivalent concepts: http://www.andrewferrier.com/blog/2006/07/24/software-change-management-should-change/.

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

> Oh, we're taking the gloves off, are we? :)

Hmm like just marking feature requests as 'dupe' but not actually giving any idea of what they may be duplicating?

http://stackoverflow.uservoice.com/pages/general/suggestions/26508
http://stackoverflow.uservoice.com/pages/general/suggestions/33552
http://stackoverflow.uservoice.com/pages/general/suggestions/26348

@dman: there are ways of arranging controls in Visual Studio now that free you from the pixel-alignment and scaling issues that you may have experienced before. You can use tables and flow panels to organise your forms and they work very well, especially if you want consistency when resizing your form.

You can create your own Windows Forms template if the Sans Serif font bothers you by the way. I would agree that Tahoma should have been the default since .NET's inception though.

As for bugs vs features, well, I agree that in many circumstances it can be difficult to tell them apart. If something is not covered in a specification document, who decides how it should be handled? Sure if you're an agile team producing an internal product, then you can safely avoid this distinction, but if you liaise with third parties who produce software for you, then it can result in unfortunate and irresolvable conflicts. Often the only way to proceed is to compromise, something many of us programmers are poor at, because it means giving up control.

What about changing the way MS Word does spell checking? It's not really broken, but it certainly sucks.

Anyhow, I recently wrote an article comparing MS spell checking and Google spell checking:
http://adotnetdude.blogspot.com/2008/11/spell-checking-right-way.html

Let me know your thoughts.

I have to fix bugs for free, for requests I can charge so there is a big difference. It is a legal and financial issue.

Bugs cause errors :)

Feature requests just go ignored because nothing is actually broken.

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

In our company, making the distinction is very important because bugs are fixed for free, while other requests result in billable hours. From this business perspective, I don't know that one could possibly avoid classifying requests as one or the other.

So many comments, someone else has probably already said it, but I want to throw in my $0.02, the question is moot.

We use a product Called StarTeam and it has something called a 'Change Request'. Notice, I didn't say a 'Bug Tracker'. We don't have 'bugs' and 'features' we simply have 'Change Requests'. A Change Request has a Priority, and it is assigned to a release.

It doesn't matter what you call something, what matters is how important it is, and having a plan for when it will be released.

Using the example of Microsoft's font problem. The font problem still exists for exactly the 2 reason I listed. One, It's importance was never measured. Two, A plan was never made for when it would be implemented and released.

So if you are currently one of those silly zealots that waste my time in meetings arguing feature vs bug, just stop. It doesn't matter.

New Idea:
1 - Consider the cost to make the change
2 - Consider how many people will be happy about it
3 - Consider how many people will be unhappy about it
4 - Consider how many people will be upset if you don't do it.

Then assign it to a release. Even if that release is a year from now.

Customers want to feel valued. Being able to tell them "You talked, we listened! Your change request will be included in version 8.7.4, which should be released in June ". This makes them feel valued.

Even more important than the ChangeRequest is gaining customer confidence. Telling the customer you listened makes them feel valued. Telling the customer you have a plan gives them confidence. And delivering on that plan, that builds trust.

@Theo and @irkregent

I suggested in a previous post that the argument is moot, what matters is how important a change is, and in your post you argued that classification is the basis for your business model.

So who's right?

Well I think whats probably happening, were using 2 different terms for the same thing. I expect you probably fix for free anything that is really important to a lot of users, and charge for all the unique requests.

I think that most enhancements or feature requests are really bugs...but not in the code. They are often bugs in requirements. If a user comes up with a whole new concept it's a new feature, but if they need something improved it's probably a bug in requirements.

I'm a little OCD when it comes to users calling "enhancements" defects. For example, your specification states "display date" so I display the date. Now if the date I'm displaying is correct - don't enter a #$(*#(& defect to make the date "purple" instead of "black" because you don't like black. That's a cosmetic issue, not a (*#&$ defect!!!!

It seems clear to me that the differing opinions here are between developers that do contract project work and developers that create shrink-wrapped applications.

@Kyle:
>>
New Idea:
1 - Consider the cost to make the change
2 - Consider how many people will be happy about it
3 - Consider how many people will be unhappy about it
4 - Consider how many people will be upset if you don't do it.
<<

If you're developing a fixed-fee project and the change, while making the client very happy, is significant enough that it will result in a financial loss on the project, it will result in very unhappy developers/managers/owners/stockholders in the development house that took the project. So what is classified as a bug and what is classified as an out-of-scope feature request makes quite a bit of difference.

In the case of a shrink-wrapped application or service, where the product/service is sold many times, then your argument makes sense since the development costs are always borne "by the house."

to sum up:
if the coder has to eat the cost, it's a bug.
if the user has to eat the cost, it's a feature.

Did you happen to see this question on SO when prepping for this post?

Telling bugs and features apart?

http://stackoverflow.com/questions/230527/telling-bugs-and-features-apart

@Bob Mc

You are correct in your analysis, my perspective is largely tied/biased to the type of development I'm doing (shrink-wrapped application or service).

Re: fixed-fee project

>what is classified as a bug and what is classified as an out-of-scope feature request makes quite a bit of difference.

On a fixed fee project, you have your requirements and what you are responsible for fixing should be very clear. If that is correctly the case, then 'trying to decide' should be a simple glance at the requirements and this whole issue again evaporates.

Jeff's original question was: "how do you tell bugs from feature requests?"

In the world of "fixed-fee projects" their should be no need for discussion. If their is an argument about it, then the problem lies in your requirements analysis.

Jeff said "The rest of the entries in your bug tracking system, the vast majority, exist in an uncertain gray no-man's land. "

And I totally disagree with this statement.

In "shrink-wrapped application or service" - argument is moot.
In "fixed-fee project" - requirements should clearly determine it.

There should not be any "gray no-man's land". If their is, your doing it wrong.

(note: I have worked on fixed-fee projects, and because of our very clear requirements, and a well written contract; what was included and what was billable was always very very clear, almost no discussion was ever needed. )

Speaking of ugly font issues, has anyone complained about your blog font? Your css is set up for "font-size:90%;font-family:calibri,tahoma,arial,sans-serif;" and it looks awful on both IE and Firefox in a fairly run-of-the-mill laptop with WinXP. I did a little testing and the culprit seems to be the calibri font - it looks fine when not scaled, but the 90% hurts the eyes.

sln

Well, I get this but "insoluble?" Really? I think this problem was solved in the 70s already. I believe there is something called a "specifications document" and supposedly everything is supposed to be "traceable" from the "specifications document" to the production system. Therefore, supposedly if there is a behavior in the production system not conforming to the "specifications document" then it is a "bug" or "defect," if you are so inclined. Just a thought.

Perhaps for those who are in the agile cult maybe there is no such thing as such a document but to say this "feature vs bug" problem is "insoluble" seems to be a bit much.

Anyway, I think the way to solve this very much depends on the sort of software being developed.

this one time at base camp i was developing with yui grids and position: relative got all messed up in ie6

and then ie6 spoke and said "I AM TEH MOST WIDESPREAD BROWSER. U MUST CONSIDER ME"

I yelled my battle cry, "I WILL L33& HAX0R YOUU!!!111" and fixed it all with pixie hacks.

That is my most exciting CSS story. - Greg

The font thing has been burning me up in the inside for all these years.

Obsolete it may be, but the problem is bigger for VB6 devs than it is for Jeff using a late VS product. VB6 does use the old MS Sans Serif as its default.

Though he missed the boat re. MS Sans Serif vs. Microsoft Sans Serif, I still think it makes sense to adapt to the system font, which must be done at runtime.

Yes, since this means size as well as face you have potential control resizing and placement issues that can kill you too.

The 'insoluble' aspect is simply that humans are the weak link. Either the client or the programmer or some intermediary got it wrong. For any project of a decent complexity, you cannot convince me that you can specify some document so perfectly that there will be no errors, either in implementation, omission, nor fickle users changing their minds.

Go ahead and take 10 years to write that document, in the meantime some of us have work to do.

@Kyle

If all my clients have the same request I still charge them. If only one of them has a bug I have to fix it for free.

This is actually a bug. The question is what kind of bug. Well, it is a usability bug. The problem is that the user would rightfully expect the default to be the font that is SET as the default font by the user in the operating system. I would be surprised if many who have not started to expect otherwise because of experience, would expect otherwise.

To the for-fee folks out there: I think it's fairly clear Jeff is thinking here only of non-contract work (shrink-wrapped isn't a good term because a huge body of work which fits this model is delivered on servers ... and who 'shrink-wraps' anything any more?). Visual Studio? Who thinks they operate on a contract fee-per-feature basis?

If they do, then someone in management at Microsoft needs to be shot. Well, I suppose someone in management at Microsoft needs to be shot anyway, but ...

One of the most obvious (to me) principles of agile development is that there is no artificial distinction between bugs and features. There are issues people have using the software we created. Some, primarily bugs but often enough missing features that we just didn't think of, keep them from seeing the way the software is SUPPOSED to work; these are a first priority because until those are fixed we have no way to judge the rest. The rest, be they bugs in the software or bugs in the analysis or bugs in what the customer said they wanted, need to get prioritized as backlog and worked from the top down.

Honestly, there's no reason why a "traditional" waterfall type of development house couldn't work the same way, erasing the false distinction between feature and bug (except where it actually HAS a purpose, such as in customer contract work), and just get things done. However, my experience with waterfall methodologies is that there's a lot more interest in accurately pointing the finger of blame that groups will spend a huge amount of time and effort bickering about where the bug was (and every feature IS a bug: something the user expected he software to do which it could not do) instead of just fixing it and shipping software. The rationale here is that no one will get better at their particular siloed jobs unless they get metrics about how well they've been doing in the form of bug counts; in reality, though, I've NEVER seen anyone improve any part of their workflow or quality of work as a result of such metrics.

A note about "every feature is a bug": the necessary corollary to that is "and not every bug will get fixed". Obviously, the "bug" that your MP3 player doesn't control their LPs isn't likely to get fixed, ever. At the same time, the bug that when you put "xyz" in a number field it silently makes it "0", while embarrassing, may well never get fixed because you have bigger fish to fry (or, you've already decided to scrap all number fields). There is this odd sense of programmer's shifgrethor about never producing bugs and bending over backwards to fix the bugs we do produce. We all produce bugs, or we wouldn't be producing software. Get over it. Fix the most important thing *to the customer* first, be that a result of your bug or a result of the customer telling you that the sky is green not blue.

The best way around the bug vs feature request argument that I've come across is to call them all Defects... if it's a bug its a defect in the way the software has been written, if its a missing feature then it's a defect in the functionality of the software - most people seem to understand this concept and it often takes the heat out of thing. Which doesn't mean that the blue screen of death isn't a bug! :-)

Competition plays great role in this. I can choose between IE and Firefox and I select Firefox. Why? Because I like it more. I like it more, because it feels better. A company can make a choice between different software vendors. Usually there are bunch of things that affect the decision, but one issue is do the users like the software in general - does the software feel good or not. The management might go for the cheaper software, but then the company has to accept the "bugs" and the fact that the software doesn't feel as good as the other. Unless the cheaper software has less but better features, of course.

Anyway, if a software vendor can create a template or such for their software, then that helps them making the software feel better in general. The vendor has then a more robust base for the development.

I like more robust software architecture too. There are architectures that are easy to use and architectures that are difficult / complex to use. When I program some logic, I don't want to know anything about little things that should be taken care of by the template.

This happened once at one of project at my work. There was one ambiguous situation with the project.
The QA opened the situation as a bug, while the developer argued that as a feature. While the discussion lasted for 15 minutes, it was fun watching that. I think each has his own motives to brand it as a bug or feature.
The other occasion was there were lot of issues with some functionality with a product. So the project manager decided that the same issues which occur in "N" version is feature while if it happens "N+1" version then it is a bug.

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

This is a rather old school way of thinking that conforms to the rigid waterfall model. It is an INCREDIBLY good designer/analyst who can drag out *all* of user's requirements at the start of a project and get everything perfect first time. In fact, so incredible that they don’t exit IMHO. That is not to say that we don’t do requirements gathering and write specifications. We do – it’s a crucial part of our quality procedure. But if you take the approach that every single enhancement the client asks for is returned with “NOT IN THE SPECIFICATION”, you’ll not be working for that client again! Sure, for the big things like “Ohh didn’t we mention the user interface has to be in French and German” but given that it is impossible to foresee everything, then you have to have a degree of flexibility. That said, the specification should define things like screen resolution and fonts if not as a constraint for the developers if for nothing else.

I read a great article somewhere that argued the case that software design carries on right until the product ships. Unfortunately, I can’t remember much more about the article. There is a lot of sense to that idea. The catch-22 situation though that all developers should be aware of is that clients *will* ask for up-front costs and you saying “But I can’t tell you that until the design is complete” just won’t wash. So one has to live in this weird world of best guesses and estimations.

The one reason I personally force myself and the team to do the requirements and specification is to force *them* to think about the entire system up front. The advantages of tackling the big problems at the start cannot be underestimated. It also gives the project leader a much better lists of tasks so at least the project can be tracked.

Cheers, Rob.

PS. We always try for the "Staged Delivery" model if at all possible whereby you expect to do another version of the program. This a) gives you repeat business with the client but also b) allows you to agree "Yes, good idea but outside the scope of the first version". The clients are often very happy with this as a) the project more likely hits it's release and b) their requirements aren't getting lost.

>Basically, to many users, a bug is when the system works contrary to how they *expect* it to work.

That is still a bug but the bug wasn't in your code, it was in the requirements gathering phase. It was, however, a joint bug by both ends.

Rob.

>What you're saying makes sense if you're working for the company that you're designing software for. If you're a custom software development shop, then it's a different situation, and gets back to "do you charge for fixing bugs"?

Ahh that's an age old problem! We have tried the idea of "one year warranty" which has sometimes works. We basically agree to fix any obvious bugs for free. I feel, that as a developer, you should do this. It's expected in almost every other industry. But this is where Bug = Fault. Given that we've agreed that user's tend to define Bug = "Anything that doesn't work they way I expect", then the discussions about what is a bug/feature request is tricky.

Rob.

Microsoft doesn't want to address the Visual studio issue and a lot of other issues too.

This Illinois license plate photo might make you smile...

http://www.flickr.com/photos/dratz/1045336659/

The title of the post remained me an indecent, that I experienced a developer who's lazy enough to look into the problem had finally said, the things which we reported is not a bug but a feature. The bug was silly and we could easily find out and fixed. :)

I'm not sure if this was mentioned earlier as there was quite a bit of discussion and I didn't read it all.

I classify all changes as either a bug or a change request and the reason I do this (I suspect its the same for most developers) is that the customer is not going to pay you to fix a bug, but they do need to pay for feature requests.

Bugs are generally defined as a crash or error that prevents the application from executing properly. Beyond that if something was in the specifications and did not get implemented, it also falls into this category. Basically anything that I was supposed to do, any issue thats my fault as the developer is a bug.

Change Requests are anything that the user would like that does not fall into the current scope statement. Signatures are always required from both parties on these as there is an exchange of money for them.

My reply here.

http://riprowan.com/Blog/tabid/36/EntryId/49/Coding-Horror-ibly.aspx

Small solution..
----------------------
Simply DON'T touch any font in the designer and in the form constructor do this ..>

public Form1()
{
this.Font = SystemFonts.MessageBoxFont;
InitializeComponent();
}

Since all controls will inherit the font from the form
(If you didnt touch the font setting on the control)
Vista users will have Segoe UI and XP users will have Tahoma
when they run the application..

Works fine in "standard" apps.

@Rip Rowan

Excellent reply!

Unless you're in the (perhaps) enviable position of having a single user, one user's feature enhancement request may turn into another user's bug report.
In the era of intertwined code and database, traditional bugs may be more fixable than other forms of unexpected behavior which do not cause crashes but do produce wrong answers. Difficult to test.
Most specs are not written by users, but by committees. Most users care nothing about specs, but how things work. Often developers don't meet users until the delivery phase (when bug/feature reports arise). I suspect the spec/committee/thou shall portion of the process is mostly at fault. If developers and users met/conferred/agreed at an early stage, everyone might be happier
How many times has that FBI case software been shitcanned? For $$$?

@Theo - Thanks.

I've expanded the reply here:
http://riprowan.com/Blog/tabid/36/EntryId/52/Bugs-Features-Defects-Who-Cares-I-Do.aspx

I've got my team using the generic concept of a product "backlog" (borrowed from Scrum).

If a change is needed to the software, whatever that change may be, it goes on the backlog. The "product manager" works with the team and a customer advocate (hopefully an actual customer) to determine the order in which the team will attack the backlog.

The whole defect vs. feature request problem just disappears!

(As an aside, Rip Rowan, classifying defects into different types rarely ends well in my experience, and doesn't add any value to the discussion. "A 'bug' is something that bugs someone." Any other view of the world strikes me as a way to get out of listening to the customer, and probably to avoid doing some work to improve the user experience.)

Usability is a feature. Perhaps the only feature that really matters...

According to Donald Gause and Gerald Weinberg in Exploring Requirements: Quality Before Design, a problem can be defined as the difference between things as perceived and things as desired. From this we can derive that both a feature request and a bug are problems, because this description fits for bugs and feature requests as well. It sheds some light on why some applications use the term "issue tracking" and not "bug tracking". GoogleCode, for instance, then uses labels to organize the various issues.

When talking to the customer I assume everything is a bug unless it is:
a) So obviously a new feature that there could never be any doubt.
b) Called a feature by the customer.
c) Contractually specified and/or important (see fixed-fee discussion).

Of course internally we handle things differently - most medium/low severity "bugs" are just lumped into the feature list and prioritized as if they were features (or vice-versa if you prefer). The high/urgent severity items are fixed as soon as possible.

So really, I guess the gray area you refer to only matters in direct communication with the customer, otherwise the distinction doesn't serve much purpose on our team, at least in terms of actually getting fixed.

>> ... applications should use the system font.

How's cursor in vista? It's very annoying the old applications have windows default cursors within their library and often ignoring the system's theme cursors.

Not to mention the very-hard-to-replace drag-drop item and shortcut cursors. I notice these two fixed in Vista.

Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!