How long should I take to fix a bug?
A day or half day works well on average, especially since most bugs are coding bugs (on average 3 hours) or data bugs (6.5 hours). Even design bugs on average only take little more than a day to resolve.
Should bugs be estimated?
You want to estimate them in the same way you estimate everything else. That means if you estimate in story points using Planning Poker, you should do Planning Poker on bugs too. If you estimate with Magic Estimation (which I find more helpful), bugs should also be on your estimation board.
How much time should be spent on Bugs vs original?
An over-zealous manager that thinks a client’s request to make a button larger (they have mouse issues) is a great way to increase the number of bugs we fixed. It will only take a few seconds to fix because there is no need to consider, testing, recompiling and distributing a patch. Oh, and it gets double-counted as a new feature.
How does the cost of fixing bugs increase with time?
The cost of detecting and fixing defects in software increases exponentially with time in the software development workflow. Fixing bugs in the field is incredibly costly, and risky — often by an order of magnitude or two.
How long does it take to fix bugs in software?
It depends on how much code you have out there, how long it has been out there, etc. The time spent fixing bugs in software should be front-loaded to the first 6-12 months of release, however as time approaches infinity, the time spent on maintenance versus the time spent on initial development will exceed 100% – that’s just the way things work.
Why do developers need to know about bugs?
As time passes and the code moves to later stages, developers need to remember everything and hunt down issues before they can fix them. If an automated system, such as a continuous quality integration, highlights issues in code when the developers are still writing the code, they are much more amenable to incorporate the fix for the same reason.