29

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?

Improve this question
10
  • 6
    When you find a bug write down what the bug was on paper. When you fix the bug write down what files were modified. Before you submit the fix, log the bug, then submit the changes. If you do this everytime you will get in a habit, you currently have a bad habit, logging bugs is not a waste of time.
    – Ramhound
    Mar 15, 2012 at 14:59
  • 5
    How can you be certain that these bugs are trivial?
    – user1249
    Mar 15, 2012 at 14:59
  • 2
    @ashansky, did you even read the second sentence of my question?
    – Philip
    Mar 15, 2012 at 17:16
  • 1
    Not logging your own work is a sure way to a) not get credit for it and b) be asked 'why isn't X done and why are you working on Y?'
    – Michael Durrant
    Mar 15, 2012 at 21:32
  • 1
    You can not log everything, its simply not practical. Why are some people jumping up and down thinking that some how not logging a few minor things EQUATE to not logging at all???
    – Darknight
    Mar 16, 2012 at 10:50

9 Answers 9

Reset to default
36

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.

Improve this answer
22
  • During the early development phase, before releasing a first version out of the engineering team then there is no need to log changes in the bug tracker. The changes will however be noted in the version control logs against each submission.
    – uɐɪ
    Mar 15, 2012 at 15:03
  • @Ian This is true, but generally during early development (assuming you mean actually developing and not exploratory prototyping or some such) you will typically be working against a feature set of some sort. In that case, each change should link against the feature(s) that it supports. Minor bug fixes down the line to a "finished" feature could still link against it to indicate support of that element. Mind you this depends on how you track features and specifications.
    – CodexArcanum
    Mar 15, 2012 at 15:06
  • 1
    @Darknight - it's not easy! It's helped by the fact we use TFS and have set it up to not allow checkins that don't have an associated work item. Yes you can override the rule, but it does stop and make you think about what you are doing.
    – ChrisF ♦
    Mar 16, 2012 at 11:35
  • 1
    @Darknight Sorry, but those numbers mean nothing. Saying it doesn't make it true; even if you could validate all of that, so what? The only conclusion I can draw from you presenting those numbers is to try to somehow position yourself above others in some way, which, quite frankly, seems futile, unnecessary and borderline rude/offensive.
    – casperOne
    Mar 16, 2012 at 14:25
  • 3
    @All Please take this discussion to chat.
    – maple_shaft ♦
    Mar 16, 2012 at 15:40
14

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...

Improve this answer
3
5

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.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
1
  • Yeah, in larger code shops the boss has "metrics" based off of this, so it's good general advice. It also leads to people abusing the bug-tracker and throwing those metrics into meaningless hell. But here it's just me and the other guy. Boss doesn't use the bug tracker.
    – Philip
    Mar 15, 2012 at 15:00
1

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?

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
-6

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.

Improve this answer
12
  • 3
    Just because it takes longer to log than to fix is not sufficient justification. Ha! this one had an explanation :)
    – uɐɪ
    Mar 15, 2012 at 14:57
  • 2
    I didn't downvote this, but if I had to guess why someone did, it's because they believe in logging all bug fixes, or they think your answer wasn't very helpful/insightful.
    – CFL_Jeff
    Mar 15, 2012 at 14:58
  • 3
    I'm not going to vote it down but I disagree with this as a general rule (although in most cases I can see it makes sense!). What if you had an "off by one error" that had shipped, but slipped through the QA net? It takes longer to log than to fix ....
    – PhillC
    Mar 15, 2012 at 15:29
  • 2
    If it's not logged then it can't be verified as fixed by QA
    – 17 of 26
    Mar 15, 2012 at 19:12
  • 3
    -1 This is just programmer arrogance ('I don't make mistakes') and ignorance (I've not seen anything bad happen with minor fixes). One really really good crash and burn from a 'minor' fix usually helps with that (also known as experience).
    – Michael Durrant
    Mar 15, 2012 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.