Bug v. Feature-an example
I don't want to beat a dead horse, which is what I'm about to do if you've already made the decision to distinguish between features and bugs in the next release. But since I haven't had a clear indication of that, here's one example of a screwup that could have been avoided if that distinction had been available.
A support rep files a feature request, the essence of which is "The program should do X." She posts it correctly to the "Features" area and goes on vacation.
The Project admin gets the new item, but doesn't notice that it's in the Features area. He thinks it's a bug report. He interprets it as "The program doesn't do X," which is subtly but profoundly different from the intended "The program should do X." Well, of course it doesn't do X, that was never a feature. He marks it as "RESOLVED-BY DESIGN," comments "It is not designed to do X," and forgets about it.
The item goes back to the originator. Nothing happens until she comes back from vacation and goggles in confusion at the resolution. Meantime, two weeks' of development time are missed while programmers work on lower priority stuff.
If FB had a bug v. feature distinction, it would be easy to make the bug pages and the feature pages different in some visually obvious way. In any event, the resolution strings would be different enough so that the admin would have realized that this was a feature item, not a bug item.
Again, sorry for the equine-flogging if this has already been decided on, but I thought it was pretty good ammo.
Monday, December 3, 2001
We love you Chris, you're the only FogBUGZ customer making noise on this forum, so of COURSE we'll do it for 3.0 :)
Here's why -- we're thinking of creating an add-in for FogBUGZ allowing customers and other non-developers to push bugs/inquiries/feature requests into a FogBUGZ database. If you buy the add-in you can use FogBUGZ as a customer-email management tool. These requests from customers need to be marked as "customer inquiries" to distinguish them from "bugs" or "feature requests." So there will really be (at least) three kinds of things.
Tuesday, December 4, 2001
Gosh, all this time I thought you hated me. :-)
Thanks, Joel. The new add-on sounds very interesting. We're already using a separate installation of FB for tracking help issues/customer requests. It would have been nicer to use a single installation, but the developers didn't want those items mixed in with actual programming items (with good reason). Since there isn't a simple way to filter them out, we had to go with the second install.
You da man, for a Yalie anyway.
Wednesday, December 5, 2001
I like the sound of that plug-in...
I've been considering employing FogBugz in a new setting (recording studio/client task managment) and one of the things I was concerned about was providing a way for everyone in the project to "speak to" FB without having to provide everyone access...
Not to cross over, but on the reporting front, being able to print out a report that "page breaks" by person, so that I can print this one report and have output that I can hand out to individuals would be great. It expands my ability to use FogBugz with a core group, but include assignments for other folks.
Lastly I agree with (I beleive) Chris, who wrote about the pychological affect of the wording. I recommended FB to a client for task management, and they couldn't get past the "Bugz" -- even in the name. And while this might be an extreme case, it does represent an issue.
As an example, in my experience bugs get written like this: "There's no milk for the coffee!" whereas tasks get written "We need to get more milk for coffee..."
Subtle maybe, but nonetheless.
Tuesday, December 11, 2001
When do you think this feature (feature/task managment) would be released?
I don't need to say how important it is.
Monday, December 17, 2001
As another FogBUGZ user, I just wanted to add that we'd like to see this feature also.
Friday, January 18, 2002
As a grunt trying to promote positive change in his organization, my 2¢ worth is that the aforementioned functionality would give me a sly way to trick a notoriously boisterous, spec-hating, ADD-poster-child project manager who comes up with 5 features a minute and loves to change database schema at will into presenting requests in a written form.
I find that when you actually sit down and plan things out, it's amazing how many things that sound great when discussed verbally turn out to be impractical or just plain stoopid. (yes, that's with a double "o")
And if I can't convice people they're wrong before wasting valuable development time, at least it would still be great to have a written history to refer to when explaining to my supervisors why an application is suddenly broken!
Friday, January 18, 2002
Oh, this seems to address my issue (see "fogbugz demo" thread) in part. It would still be great to be able to modify the individual tags or titles on items on a per-project basis so that fog creek doesn't have to "guess" what the "columns" or fields for each type of item should be. For that matter, removing the cap on number of fields would be awesome too. After all, what's the difference between a bug report and a feature request? Very little. Well, maybe the workflow would be different for a request, but even there, if the administrator could have enough control over these things, fog creek could focus on adding some really new kick-ass functionality instead of adding a new field for every person that needs one, not only making this a more over-all versatile tool, it would... well... make this much more versatile.
I just realized that a related project in my company has a manual process for getting requests for new features, and this could go a long way towards organizing that. They're looking at e-Room right now because of it's "many other featuredness" but if this fits the bill nicely, why use a backhoe when all that's needed is a spade?
Friday, January 25, 2002
Fog Creek Home