The first key premise of effective bug tracking is the concept of ownership. Ownership is crucial in software teams because without ownership there is no responsibility, and without responsibility there is no direction. In order for a bug to get fixed in a timely manner there must, at all times, be somebody, a single individual, who is personally responsible for ensuring that that particular bug gets fixed. This person may be a programmer, but it could equally be the project manager or someone else. All that is important is that there is one person, and no more than one person, to be held accountable.
If this all seems obvious so far, consider that in many bug tracking applications, bugs are entered and then remain unassigned until somebody goes in and chooses who will deal with the problem. Where’s our accountability there? From the bug tracking application’s perspective at least, there is nobody responsible. We can do better than that. Golden rule number one is this:
“From the point at which the bug is entered into the system, and at all times afterwards, there will be somebody, a single individual, who owns that bug.”
In other words, there can never, at any time, be such a terrible thing as an unassigned, unresolved bug.
So how do we achieve this? Who does the bug get assigned to when it is first entered?
We could let the person who reports the bug decide, but more often than not the bug reporter is a software tester. They may well know who is the best person to assign the bug to, but we shouldn’t assume that they do. Futhermore, a software tester really shouldn’t, and probably won’t, have the authority to decide the workload of individual developers. All-in-all, it’s probably best that we remove these destructively-minded pessimists from this decision-making process.
Ideally the system should be able to provide us with a sensible default owner. Fortunately this is pretty straightforward to achieve. If we apply the same ownership rules to projects that we have applied to bugs, every project in the system will have an owner. Therefore every bug reported against a project has a ready-made default owner.
This approach works great for small projects with just one or two team members but doesn’t really scale. With a team of 20 developers the project owner would have to go through the list of bugs and re-assign each one to an appropriate team member. This is not much of an improvement on systems that leave the bugs unassigned initially.
This problem however is just one of granularity. By allowing projects to be sub-divided into components (and of course having an owner for each component), we can make the approach scale quite nicely. Bugs are then reported against components and initially assigned to the owner of that component. When components are added to projects their default owner is the project owner, but this can be over-ridden.
The sub-division of a project into components must necessarily be quite coarse-grained. Bugs are reported by testers and these testers must easily be able to identify the various application components without an intimate knowledge of the implementation. I see no reason to further divide components into sub-components. There is little to be gained from such a hierarchical composition.