Fog Creek Software
Discussion Board

Reports, Bug/Feature field

Well, OK, so I'll start the first topic.  I have two enhancement requests:

1. The FogBugz philosophy is that if you want tabular reports, you get them by running Access on the fogbugz SQL database.

This may be fine for most people, but about half of our team (including me, the Admin) can't get any reports because we're not located in the home office and we can't get to the SQl server (due to network proxy settings).  This means that the only way I can get a report is to ask someone in the home office to create one and mail it to me--not particularly convenient!

I would really like to see a reporting feature added to FB.

2. -EVERYONE- on our team would like an intrinsic Feature/Bug distinction for items.  We don't treat them the same way, and much of the verbiage for bugs is inappropriate for features.  We realize that we can "sort of" do this by using separate projects or areas, but this really isn't the same (and it unnecessarily doubles the size of the project/area tree).

And them's my thoughts. Kudos to Fog Creek for releasing a product for which I can only come up with two serious suggestions.  You should see my list for the OTHER new product we installed recently.

Chris Dunford
Wednesday, October 17, 2001

I've been hearing a lot of that. Do you just want a checkbox that lets you select whether a given item is a bug or feature? Or do you want a whole separate feature-tracking UI (so, for example, you have to choose New Bug or New Feature).

Joel Spolsky
Wednesday, October 17, 2001

It is a different UI, not just an attribute of the item (although you could certainly store it that way internally). You need to select New Bug or New Feature, and you probably can't change one into the other after it's created.

Then you have to go through the UI and adjust the verbiage. For example:

- "Fix for" becomes "Implement for", "Enter an estimate for this bug" becomes "this feature", etc.

- The priority strings and resolution strings are different ("NOT REPRODUCIBLE" makes no sense for a feature, for example).

- Lots of references to "bugs" become "items", e.g., "My Bugs" becomes "My Items", "Go to bug #" becomes "Go to item #", etc.

Also, you'd need to add Bug/Feature/All to the filters.

Chris Dunford
Wednesday, October 17, 2001

I really appreciate this suggestion and we've had it from a couple of people (not just Chris).  I just really want to understand "why" some people can't just call a feature a bug.

I'm so confused, and maybe its because I've always been using FogBUGZ as a general "tracker" app.  (e.g. we have a FogBUGZ Project which is "Corporate Headquarters" and an example bug in there is something like "The toilet on the second floor is clogged".)  I still don't understand the overwhelming desire to add a whole different UI for features.  To me, features are just bugs.  For example, say you want to add skins to your app.  Why wouldn't you just make a bug that says "We need to add skin feature to app"?

Basically you want some verbiage and structure to change in the app, and I believe it will just make things more complex for the end user (you).  I think in reality, you think you really want to have FogBUGZ support a division between bugs and features and that it will make things "cleaner", but when it happens you will have just made your life harder and your UI clunkier.  Bug tracking systems die a slow painful death as you add more and more fields to each bug.  People end up just not filling them out (and then not using the bug tracker).  Plus then the filter screen would have a whole 'nother field, and when you create a new bug, you'd have a whole 'nother thing to check off...

I think you might be able to convince me if you say you just want a combo at the top of the bug edit screen that says "bug/feature" and then add it to the filter screen, so you can get lists of features and lists of bugs.  But I need some more arguing before I can be pursuaded :-)  Tell me more about *why* you really want this feature, in respect to what you would use it for.. what new things could you do with it that you can't do now? (or what things could you do easier that are hard now)?

Michael Pryor
Wednesday, October 17, 2001

In my experience, it has a bit of morale influence.

When coming to the end of a version, we had a close eye on the number of bugs every day. When people started putting feature requests in as bugs they showed up in the bug count report.

So at the end of every day, I would look at the report and find I had more "bugs" than I had started the day with.

Having them filed as "Feature Requests" makes it look like a feature that someone wants, not a defect in my code. So I finish the day happier.

Thursday, October 18, 2001

I know of a programmer/author who says, "A user interface is well designed when the program model conforms to the user model."  The guy is pretty smart (except when he is saying that "all good hackers started programming computers in junior high school").

Anyway, the user model is that features are NOT bugs.  FB insists that they are.

As Damian very correctly says (and as I said in an email to you some time ago), a lot of the difference is psychological.  Programmers are sensitive.  My experience is that really good programmers trail only fighter pilots and surgeons when it comes to ego.  Now, what do good programmers hate more than anything else in the world?  Someone calling something a bug that is not a bug.  Bugs are anathema.  They are insults.  They represent incompetence, slovenliness, carelessness, stupidity.  The word "bug" is hateful to us.

Now, what has every programmer who has released a nontrivial application into the cold, cruel world experienced?  The user message in a public place that says, "There is a **BUG** in CockRoach 1.0.  There is a Number of Antennae field but no Number of Legs field."  This causes programmers to throw up.  It's not a bug; CockRoach is working exactly as designed and as coded.  The user is calling something that doesn't work the way HE thinks it should a "bug."  We HATE that.

And the bug/feature dichotomy isn't apparent only to programmers.  I introduced fogbugz to our team member individually.  About half of the team consists of support people, not programmers.  I couldn't help but note that EVERY SINGLE ONE OF THEM asked, "How do I specify whether this is a bug report or a feature request?"  I am not exaggerating.  EVERY one of the other people (nine of them) asked this question.

But there's more to it than just morale and psychology.  Every time you use bug terminology (fixed, reproducible, as intended, version found in) you are forcing the user to mentally interpret what these might mean for a feature and to come up with the most logical equivalent.  There is a mental disconnect that slows everything down and makes the product harder to use, not easier.

1. "To me, features are just bugs."  Well, not to us.  There are many differences.  Probably the biggest is that users have seen bugs (most of them, anyway) but they have not seen features.  We believe that fixing most bugs is more critical than adding most features (regardless of what Microsoft thinks about this).  There's a big user difference between "I wish it did this" and "This crashes my machine" or "This gives me incorrect results."

2."I still don't understand the overwhelming desire to add a whole different UI for features."  It's a -slightly- different UI, not a -whole- different UI.  A new button and some string changes.  It's just not that big a deal as far as the UI is concerned.  The UI is improved because what you see on the screen makes more sense for the type of item you're dealing with.

3. "I believe it will just make things more complex for the end user (you)."  Don't see this.  Again, all we're ADDING is one main menu choice.  The remaining changes basically amount to changing text to something that makes sense for features.  What's the big deal?  In many ways, the UI gets easier because the text fits the situation--we don't have to mentally interpret bug terminology to some equivalent in feature terminology.  What meaning does "RESOLVED - NOT REPRODUCIBLE" have for a feature?

4."Bug tracking systems die a slow painful death as you add more and more fields to each bug.  People end up just not filling them out (and then not using the bug tracker)."  Absolutely.  The tracker I'm most familiar with has 37 widgets on the bug entry form plus two buttons that say "More Choices".  Most of the fields are required.  I don't want that, and that is why I recommended fogbugz.  But I'm not asking for that.  This is one additional critical field and some string changes.

5. "I think you might be able to convince me if you say you just want a combo at the top of the bug edit screen that says "bug/feature"" What's the difference in terms of UI complexity between this and adding one button to the main menu?  The advantage of the new button as opposed to the form combo is that the button allows you to tailor the terminology to the item.

None of us wants to make fogbugz into the sort of rigid, overly complex bug tracker that dominates the market today.  Don't add every minor feature that one user wants.  We love how simple and clean it is.  But, when Joel says "I've been hearing a lot of that" maybe it's time to sit up straighter and think, "Maybe our users don't see this issue quite the way we do."  :-)

Chris Dunford
Thursday, October 18, 2001

Thanks Chris... your reply was exactly what I was looking for.

Michael Pryor
Thursday, October 18, 2001

Glad to help, Michael. :-)

I did think of one thing that is not possible (as far as I can figure) with the current FogBUGZ--I don't think there is any way to set up a filter to display only features or only bugs (for all projects/people).

You asked what could not be done with the current implementation, and I think this is one specific item.

Chris Dunford
Thursday, October 18, 2001

I agree that a bug tracking system needs to differentiate bug reports frm feature requests.

I also agree that a bugtracking system as nice as FogBugz can and will easily be repurposed as a feature requesting system.  Users (tester) will just naturally use it that way, to tell programmers what is missing.  To them a "missing feature" is a bug.  Just as managers will use it as a wider project management tool because, if all you have is a hammer, everything looks like a nail. 

I think the answer for programmers (for whom a bug is more narrowly defined as an existing feature which is broken) to get the most out of FogBugz, is to allow Administrators to "resolve" bugs by designating them as feature requests, and thereby *hiding* them from programmers whose job is simply to emply the list of *broken* features, and move these to a place where users can manage their wish-lists, and managers can decide which are to become features, and then assign those to programmers (hopefully only after they are properly specified).

David Kaufman
Thursday, October 25, 2001

*  Recent Topics

*  Fog Creek Home