Should I log trivial fixes?

Question

I'm in a code shop of two. And while I understand that a bug tracker is useful where the number of programmers is greater or equal to one, I'm not so convinced that logging bugs, changes, and fixes is worth the time when they're trivial. When I find a simple bug, I understand it, fix it, and run it through some testing. And THEN I realized I need to go log it.

I know in theory that bug logging should be done somewhere between finding the bug and fixing the bug, but if fixing it is faster than logging it, it seems like a drag. In larger code-shops, the boss pays attention to who is doing what and it's nice to know where others are mucking about.

I find myself describing things that I've already fixed and then instantly closing them. I have doubts that anyone will ever look at this closed bug again. Is it time to trim the process fat?

Answer 1

You should log every change you make to your system. There's nothing wrong with logging it after the event - as long as you link the bug report to the change number.

Then if anything ever goes wrong you can track back to the bug and find out why you made the change you did.

In the vast majority of cases you are right and no one will look at these ever again, but in the 1 out of 100 when something does go wrong this information will be invaluable - especially if the problem only surfaces 6 months down the line.

UPDATE

Obviously if you are still developing a new feature and discover a bug in part of the feature you thought you'd finished it's not necessary to log it as a separate change. In these cases I'd log it against the item requesting the major feature.

Once the system with the feature has been passed to QA or the customer, then it's necessary to do what I outlined above.

Answer 2

If you use a source control tool, then you can describe the bug you fixed in the commit description and that is usually sufficient documentation for super-small, trivial bug fixes.

Furthermore, if you use a bug/feature tracker that is fully integrated with your source control and repositories, like FogBugz and Kiln, you'll be able to use the global search tool to find these bug fixes and see what code changes you made quite easily.

Plus, you can assign a code review to your programming partner so he can review the trivial fix you made, but I digress...

Answer 3

From a metrics point of view, it may well still be useful.

This information could be used to show the boss a number of things:

• we need more developers
• something else in the process is broken (why so many bugs? does the other guy generate most of the bugs), maybe showing you have too many bugs. Maybe there is something causing this? are you releasing too early? is enough testing being done?
• a good list of what you have been working on come bonus time.

That all being said, it depends how small a bug you are talking about. One liners you happen to spot while adding new code would probably be pointless to log for example.

Answer 4

I try to log every change I make regardless of the size of it. You never know when you, or someone else (future or present), will need to go back and see if that change is the possible cause of something else.

Answer 5

Tracking is important, but consider another scenario as well: when it comes time for your review. It will happen formally in person, or informally without you there via your boss pulling up reports from the bug tracker.

Consider them 'gimmes' that end up boosting your numbers. After all, they are bugs that you've fixed, and you should be recognized for fixing them, even if they are trivial fixes.

Log them.

Answer 6

To answer this really depends on where you are in the process.

These can apply to a new project or a new feature set being designed.

Initial Design If you find bugs on code that we created during initial design then creating a bug track for it would not be necessary. I would suggest a separate commit for the change so you can easily unwind it if you find a problem later.

Testing

Code is usualy still conidered imature during unit testing so unless it is done by a different group I would say no. If unit testing is done by a different group than a bug tracker is a good way to formalize the testing procedure.

CSCI testing depends. Is it done by another group? If so then yes (see above). Is this the last step of testing before release? Then yes, because at this point your software should be considered mature. If you are interested in metrics then it would also be good to start tracking bugs at this point.

For any higher level of testing then you should use bug tracking. At these points your software should be considered mature and tracking bugs is important.

Release

You should always track bugs on released code. This is important for accountability.

Streamlining a process to fit your needs is also important. Do you really need a huge bug tracking system? Are all the fields really that important for a team of 2 people?

Answer 7

Is it possible that someone else could encounter the bug, perhaps in an older version of the software that's been released to the outside world? If so, then logging both the bug and the fix can be useful.

Others have suggested that if it takes longer to log the bug than to fix it, then it's not worth logging. I suggest that the relevant time span is not between finding the bug and fixing it, it's between the time the bug was introduced and the time the fix is released.

If the change and release history indicate that the bug has never seen the light of the day, then logging the fix when you check it into source control should be sufficient.

This is pretty close to this question, but I'm not sure it's a duplicate, since this one focuses on trivial fixes.

Answer 8

Why you shouldn't track bugs, by Jon Arid Torresdal - fix them instead.

1. During development: You encounter a bug for a feature; you add a test case that breaks the build, then check in the fix against the feature.

2. After release: document the behaviour. If you plan on releasing an update, goto 1. If you're not in charge of that release, keep the test+fix stashed in a private branch.

After code is released, there may be other priorities, and while fixing the bug may be trivial, distribution of the fix may not be economical on its own, unless you're doing continuous deployment.

Answer 9

Depends how trivial, I use this measure:

If it takes longer to log it than it took to fix it, it ain't worth logging it.