Steven E. Newton
Crater Moon Development
Use a Tracking tool
Post-it notes, programmer’s memories, even email, are difficult to coordinate on a team of more than 2 people working together for more than a few days. The tool doesn’t have to be sophisticated – it can be a spreadsheet – but it must be shared.
Automated TODO list
Each item the bug tracking system is assigned to one person and has a priority associated with it. The list of bugs becomes a personal, automatically updated and prioritized, TODO list.
The bug report has a life and grows with changes. Documenting that aproblem was worked on and resolved represents a knowledge base.
Untracked bugs can lead to wasted or duplicate effort. The wrong programmer attempts to fix it or multiple programmers all work on different solutions at the same time without coordination. Or a programmer works on an already-fixed bug not knowing that the fix is in. The bug isn’t really a bug, it’s a new piece of functionality, leading to scope creep. Low priority, easy, or “fun” bugs get fixed before the higher priority bugs. Assign bugs to one person at a time, and give that individual responsibility for resolving it or assigning it elsewhere.
Differentiate Priority and Severity
The affect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time. Track the two separately, then triage appropriately. It helps to have input from others on the team on priority.
A Bugs Life Cycle
A bug can only be assigned to one person at a time. That bug may flow back to the reporter with a misdiagnosis or fix that doesn’t work. The assignee may assign the bug to another programmer more familiar with the fault or for review. It may go back and forth from reporter to programmer a few times before it is fixed and resolved.
Fixed is not Closed
Once the programmer has made code changes and checked in the results, that programmer can mark the bug fixed, but cannot close it. The user who entered the bug is responsible for verifying and closing the bug if it really is fixed. The resolution of a bug should be different from the status. “Will not fix” or “Unable to reproduce” are among the other resolutions besides fixed that can close a bug.
Incidents and Faults
It should be a given that the same bug can cause different apparent problems to different users. It is also possible that a single reported problem may be traceable of multiple different faults. Therefore, several reported failures that arise out of the same fault should be tracked together. Consider splitting a single bug with multiple causes into a bug for each fault, and relate them as above.
Reviews Before Big Changes
Sometimes a bug or group of related bugs will result in a change that affects large sections of the codebase, or significant changes to one component. In these cases, before the programmer commits the changes to the team source repository, assign the bug report(s) to a reviewer, typically a team lead, senior programmer, or module owner. The reviewer can examine the proposed fix for compatibility, suitablity, and overall conformance with direction of development. Reviewers should be timely in their responses, and reassign the reviewed bug back to the programmer with approval or suggestions for changes. Once reviewed, the programmer should go ahead and check in the fix.