[ACCEPTED]-Bugs versus enhancement versus new feature-bug-tracking

Accepted answer
Score: 20

This choice is called triage, a term from 40 emergency departments in hospitals where 39 they have to decide who gets treated (and 38 sometimes, unfortunately, who lives and 37 dies).

As with all business decisions, it's 36 a cost/benefit problem. What is the benefit 35 of fixing a bug or adding a feature? What 34 will it cost (including the opportunity 33 cost of not doing something else)?

Pick those 32 that have the most benefit for least cost. What 31 you're aiming for is the maximum bang-per-buck. Resources 30 are limited, desires are not, the perennial 29 problem of capitalism :-)

There's no point 28 fixing a bug experienced by only one customer 27 who's never going to throw more repeat business 26 your way if it means a feature that will 25 sell hundreds of copies is dropped in the 24 meantime.

For what it's worth, our company 23 has a database of requested changes where 22 customers can basically vote for what they 21 want to see in upcoming versions of our 20 products. The actual creation of these requested 19 changes in that database is limited to the 18 sales force since we don't want all sorts 17 of requests showing up without being evaluated 16 and discussed at least a little bit with 15 the customers.

In addition, we regularly 14 approach our biggest customers (in terms 13 of revenue generated) with the list to figure 12 out what features should be added (they 11 are free to suggest their own desires as 10 well, which also get entered into the database 9 - obviously voting power depends a bit on 8 revenue).

This is quite separate from our 7 bug system although quite often bugs are 6 raised which are actually new feature requests, and 5 they're shipped across to the new features 4 database. It's possible that this may even 3 happen for real bugs that are considered 2 low-impact or have a suitable workarounds 1 in place.

Score: 4

We ask our users. We have a niche product, and 16 a small user base.

Seriously, the users group 15 are paying maintenance, or thinking about 14 buying.

So we ask them what they would like.

They 13 suggest fixes, ask for new features.

We tell 12 them about the development roadmap: because 11 we have things we want to do to the product 10 , due to times changing, design ideas. Changes 9 to regulations.

And if every customer says 8 "we really need feature X" : then it'll 7 come next.

If they say "you guys need to 6 fix the bug where I click there an it doesn't 5 do blah:" then that bug gets fixed.

Commercial 4 software: with the customers voting for 3 changes. Of course, we take their choices 2 on advisement: the company have other things 1 that are thinking about.

Score: 3

We always look at the cost of fixing the 7 bug versus the problems caused by it. Sometimes, it 6 just isn't worth it to have every single 5 bug properly triaged, root caused, then 4 fixed.

Plenty of times a particular enhancement 3 or new feature is being funded or at least 2 strongly recommended to occur by a large/good 1 customer, so that also affects matters.

Score: 2

I like to think that bug fixes should always 5 come before enhancements and new features, in 4 all cases. Even if the particular bug isn't 3 bothering you too much as the developer, someone 2 somewhere is having their day ruined when 1 your little error pops up.

Score: 1

distinguish, yes.

bugs take priority, yes.

all 9 critical / normal priority and above bugs 8 first, yes.

yes, the 80/20 rule.

no, bugs 7 and features have to be treated differently 6 because they are weighted differently.

yes, all 5 commercial, open-source, and in house applications 4 have their own way to do things.

As an example, FogBugz 3 uses Evidence Based Scheduling and is the 2 only management/tracker that i know of that 1 uses that formula.

Hope that helps!

Score: 1

You have to look at it from the standpoint 26 of what the bug is. A show-stopper bug is 25 always number one priority. If people can't 24 log in or critical data can't be entered 23 or adjusted, etc. then that must take precedence 22 over pretty much everything.

Bugs of lower 21 significance can be worked in as need be. We 20 may delay fixing a bug becasue we know we 19 are working on that section for an enhancement 18 next week. Then the bug fix will go with 17 the enhancement. We may delay fixing a bug 16 if it is minor and a planned enhancement 15 will replace the code entirely shortly. A 14 major enhancement might take precendence 13 over fixing some typos on the interface. A 12 client may tell us that this other project 11 is more critical and to do it before fixing 10 the bug (our software is highly customized 9 by client). It all depends on the affect 8 of the bug and existing plans and corporate 7 politics once you are past the show stopper. A 6 bug that is bothering a major client may 5 take higher precedence even if it seems 4 minor to the developer. If the CEO wants 3 it fixed now, doesn't matter how unimportant 2 it seems compared to the rest of the workload, it 1 gets fixed now.

Score: 1

Point 5 of The Joel Test: 12 Steps to Better Code makes a compelling argument 2 (in my opinion) that it's a good idea to fix bugs before 1 writing new code.

Score: 0

For bugs, it's pretty simple: If you're 6 going to fix it, fix it before you write 5 any more code. Why? The more code you 4 add, the harder the existing bug will become 3 to find.

If you're okay with the idea of 2 the bug never being fixed, by all means 1 triage it over and add features.

Score: 0

Bugs? We have no bugs. They're undocumented 13 features.

For us the choice is always based 12 on business decisions and as a developer 11 I have no input beyond offering my opinion 10 on what should be top priority. More often 9 than not, features win over bugs because 8 adding features "appears" to the business 7 area like progress is being made and bugs 6 that I could have fixed a year ago continue 5 to exist because the business side only 4 wants to see "progress". Triage is great 3 if your allowed, but all too often in the 2 corporate environment, it's about visible 1 results, not functionality.

Score: 0

One thing did not mention so far the severity 5 of the bug. If the bug has high severity 4 (like crash , can not pass duration test, and 3 it surely depends on what kind of application 2 you have) ,you should definitly fix it first 1 before adding new feature.

More Related questions