Keeping it clean
Filed under: Development, Management, Process, Product Management, Project Management
The bug databases which are used as they should be, are very susceptible to having a back log of old issues (bug rot). These old issues will grow and grow as time marches on. Any reasonable person who examines of the size and requests in the database results in the conclusion that they can’t all be resolved.
During a triage we ask, “When should we fix this issue?” The response typically is either, “Now” or “Next Release”. Many people are afraid to ask this question, “Will we ever fix it?” There are some issues that we will actually fix in the future, but that list will always be smaller than what we won’t fix in the future. If we are never going to fix them, why do we keep them around in an open state?
There are several reason people choose to push a bug to the “Next Release” instead of choosing not to fix it. By telling a person we aren’t planning on fixing your issue, it leads to longer triage meetings since you will have to have a more vigorous discussion on a bug closure. It is much easier to placate with a, “We’ll fix it in the future, we’ve got a release to get out the door right now”.
I’m a person who enjoys stats and the bug database. When the bug database is properly used by the developers, it is a good way for me to get a feel as to the quality and progress of a release. The result of choosing to move your issues to the “Next Release” instead of considering closure will cost you in the long run in the following ways:
We have to constantly discuss these same issues again and again is insane. When we are releasing M6, we are moving many issues to M7 since we know that we won’t have time to resolve them in M6. Once we start development of M7, we go over all the M7, moving many of them to M8. Repeat this process again and again. This results in us having to discuss these same issues again and again. Those issues that we continually bump will never get fixed. Close them as “WONTFIX”, man up and just do it.
Zarro boogs found
It clutters up the view for the developers. It is much easier for a bug to get forgotten when you have 200 assigned to you, instead of only 22. Seeing that my bug list empty, is just as satisfying as all of my unit tests as green.
Measuring the health of your components is much more difficult. With all of these old issues cluttering the database, the view of the software components health can become skewed. I could see in the database that there are 420 bugs against “Component A” which could be in a much better state than “Component B” with only 80 bugs against it.
I use the database to do bug glide slope projections to help me determine if we are converging or diverging. Carrying a large amount of bugs make the projections more cluttered.
I will say that there has been a couple of times where I’ve broken the “WONTFIX” rule. There have been requests from the senior management team which are clearly impossible (usually defying the law of physics), and no amount of discussion can get them to drop it. These bugs get logged, and targetting approatiely. We typically visit these in the begining of the release cycle to ensure that they are given due consideration so that when we can provide an intelligent response.