Collective Wisdom from the Experts 77
Changing the status of a bug—e.g., Open to Closed—is a public statement of
what you think of the bug. Taking the time to explain why you think the bug
should be closed will save tedious hours spent later on justifying it to frus-
trated managers and customers. Changing the priority of a bug is a similar
public statement, and just because it’s trivial to you doesn’t mean it isn’t stop-
ping someone else from using the product.
Don’t overload a bug’s fields for your own purposes. Adding “VITAL:” to the
subject field may make it easier for you to sort the results of some report, but it
will eventually be copied by others and inevitably mistyped, or will need to be
removed for use in some other report. Use a new value or a new field instead,
and document how the field is supposed to be used so other people don’t have
to repeat themselves.
Make sure that everyone knows how to find the bugs that the team is supposed
to be working on. This can usually be done using a public query with an obvi-
ous name. Make sure everyone is using the same query, and don’t update this
query without first informing the team that you’re changing what everyone is
working on.
Finally, remember that a bug is not a standard unit of work any more than a
line of code is a precise measurement of effort.