I work primarily on small-scale (and large-scale) software projects. One of the questions that always needs answering is how do we decide how many bugs should we fix?
Realistically, software always has bugs. And these bugs are of different types; data corruption bugs are not the same as the-border-color-is-wrong bugs.
Some project management methodologies answer this question directly or indirectly; Six Sigma comes to mind (leave no more than one bug per one-point-something-million), as do Clean Room and Zero Defect methodologies (no bugs allowed, period).
But how do I decide how many bugs I should fix? What do I look at? Some metrics might be:
- How many bugs do I have budget for fixing (fix as many as possible until launch)
- How many customers are complaining about bugs (fix bugs that multiple people complain about)
- Severity of bugs (fix data-corruption and software-halts bugs only)
To summarize and clarify, I'm looking for a method or technique I can apply to come up with a set of guidelines on which bugs to fix and which to ignore.