28

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?

Philip
  • 6,742
  • 27
  • 43
  • 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 '12 at 14:59
  • 5
    How can you be certain that these bugs are trivial? –  Mar 15 '12 at 14:59
  • Impact assessment is a skill that works off your knowledge of the system, but I understand where you're coming from. There are fixes that seem trivial but have deep ramifications. In general, if I'm unsure, it's not trivial. And I consider knowing what you don't know to be the key to wisdom. – Philip Mar 15 '12 at 15:05
  • Are you talking about just logging the bug *somewhere*, or logging the bug in some bug-tracking software? I think you're fine as long as you log it somewhere, but I don't necessarily think you need to log trivial fixes in your bug tracking software, especially if they're not fixes that were causing a bug, such as spelling corrections. – Rachel Mar 15 '12 at 15:05
  • I think that a bug tracker is useful where the number of programmers is greater than zero – ashansky Mar 15 '12 at 16:37
  • 2
    @ashansky, did you even read the second sentence of my question? – Philip Mar 15 '12 at 17:16
  • @Philip lol I could have sworn that said two when I read it. – ashansky Mar 15 '12 at 17:18
  • @ThorbjørnRavnAndersen, a trivial bug could be a display bug. `printf("type your namehere:");` has a trivial bug fix `printf("type your name here:");` – Thomas Eding Mar 15 '12 at 19:21
  • 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 '12 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 '12 at 10:50

9 Answers9

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.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • 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 '12 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 '12 at 15:06
  • +1 for advocating the documentation of _why_ the change was made. – semaj Mar 15 '12 at 15:44
  • so much easier said than done... – edthethird Mar 16 '12 at 01:27
  • ChrisF, as **Noble"** as your advice is, in the real world its not **practical** to log everything! I would like to ask: **"have you personally logged everything?"**, I suspect I know the answer. So I disagree with your answer. But that doesn't mean I'm going to down-vote you ;) **(yea you guys know who you are)** – Darknight Mar 16 '12 at 10:46
  • @Darknight - In the past I haven't logged everything, but I do now. Having that record linking a change to a bug or enhancement is vital. One reason is so you can decide what to merge into the release line and know that what you do merge has been tested. – ChrisF Mar 16 '12 at 10:50
  • I'm **finding** it hard to believe you log everything, I have but your word (and if you say you do, then I accept this). However I feel the impractically of logging everything is a real world problem. Which not everyone has had the fortunate to overcome as per yourself. – Darknight Mar 16 '12 at 11:27
  • 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 '12 at 11:35
  • @Darknight - says who? Any professional software developer ought to log everything. I know plenty who don't. All the better software developers that I've worked with log absolutely everything. – Dawood ibn Kareem Mar 16 '12 at 11:42
  • @DavidWallace its that word again "ought to" and all that shebang. I'll put it here, I can't speak for **others**, I can only speak for myself and **my** experience. I've got experience of well over 30+ projects; I have **almost** 0 bug rate. Some of my applications will be now have been running 24/7/365 for over 8+ years and zero crashes or errors. I haven't logged "every thing" *(probably because I have not needed to change much)* I think I my track record classifies me as a "better" software developer... – Darknight Mar 16 '12 at 12:03
  • We have a hook on our VCS that checks that our commit message has a bug number in it and fails the checkin without it. It links the commits to each case in our bug tracker. It's all automated and makes very easy to see all the work done on a given case. – Michael K Mar 16 '12 at 12:28
  • 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 '12 at 14:25
  • @casperOne I'm not presenting myself above any one. What it does prove is that the whole **"you must log everything"** or the universe will implode mentality is something that not only do I disagree with but my in my experience is simply impractical and unnecessary. If you believe otherwise **fine**, live long and prosper. – Darknight Mar 16 '12 at 14:48
  • @Darknight What I believe is irrelevant. What I'm asking is how those unverified metrics by which you are measuring yourself support your position? – casperOne Mar 16 '12 at 14:52
  • Cool any others want to jump up and down on my back? I must say some of these remarks are childish/rude. I've **liked** the responses from ChrisF *(polite and cordial)*. The others **frankly** have irked my other wise chilled and laid back style. I'm going to go for a walk and chill-ax before I type something rude... – Darknight Mar 16 '12 at 14:54
  • @casperOne it proves that one doesn't require **"to log everything" (tm)** for a successful project. How far do you want to take this? – Darknight Mar 16 '12 at 14:58
  • @Darknight I'm trying to establish the correlation between your (still unverified) metrics and how it supports your position. Based on your response I don't think there's any further to take it, you've shown that there really is none. Thank you. – casperOne Mar 16 '12 at 15:04
  • @casperOne **think very carefully** about what you said; lets assume these "unsupported" *(you don't believe me, by that logic I have no reason to believe ChrisF's earlier statement)* metric. The premise is that one requires to "log everything"; I posit that some things can be **omitted**. The **assumption** is that **logging** is the ONLY method to determine what went wrong. This is clearly and factly wrong. The real world (my metrics) show a perfectly clear correlation --> I didn't log everything --> projects are fine. – Darknight Mar 16 '12 at 15:10
  • @casperOne you have established nothing, disprove my last comment. Or move on. – Darknight Mar 16 '12 at 15:12
  • @Darknight The burden of proof isn't on me. They're *your* achievements, *your* metrics. I can't disprove something which isn't substantiated. – casperOne Mar 16 '12 at 15:28
  • @casperOne fine, then prove this which does NOT involve metrics : That logging is the **ONLY** way to determine what has gone wrong in every case. – Darknight Mar 16 '12 at 15:33
  • 3
    @All Please take this discussion to chat. – maple_shaft Mar 16 '12 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...

CFL_Jeff
  • 3,517
  • 23
  • 33
  • 1
    Yeah, I do that. Although sometimes I do find myself fixing things while in a branch and bundling them up into other commits. – Philip Mar 15 '12 at 14:52
  • 1
    For reference, [here's a combined list of issue trackers and source control they integrate with](http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems#Revision_control_system_integration) – Matthieu Mar 15 '12 at 16:34
  • @matthieu Wait, Jira integrates with SVN? My goodness, why aren't we doing that? Looks like there's a couple of plug-ins. – Philip Mar 15 '12 at 17:21
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.

ozz
  • 8,322
  • 2
  • 29
  • 62
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.

Corv1nus
  • 933
  • 1
  • 8
  • 13
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.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • 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 '12 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?

Charlie
  • 163
  • 1
  • 5
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.

Community
  • 1
Keith Thompson
  • 6,402
  • 2
  • 29
  • 35
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.

Henk Langeveld
  • 348
  • 2
  • 10
-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.

Darknight
  • 12,209
  • 1
  • 38
  • 58
  • ha! down voted with no explanation, the best kind ;) – Darknight Mar 15 '12 at 14:53
  • 3
    Just because it takes longer to log than to fix is not sufficient justification. Ha! this one had an explanation :) – uɐɪ Mar 15 '12 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 '12 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 '12 at 15:29
  • @Ian Well, that's fine in my world its sufficient justification, but I guess others it may not be. – Darknight Mar 15 '12 at 15:55
  • @PhillColeman that's cool, that's my ethos too, I only down-vote if its just plain factly incorrect. But If I disagree, then hey you say "foo" I say "fuu"... – Darknight Mar 15 '12 at 15:58
  • 2
    If it's not logged then it can't be verified as fixed by QA – 17 of 26 Mar 15 '12 at 19:12
  • @trinithis :) perhaps http://en.wikipedia.org/wiki/Ain't – Darknight Mar 15 '12 at 20:04
  • 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 '12 at 21:26
  • 1
    Plus 'one persons minor fix is another persons module re-write' i.e. there is usually no "standard" for minor, although some sites (like the stack change exchange network) use 6 character changes or less as "minor". I'm not entirely sure how they do it as pure character length would be a poor measure and could still represent a big change. One improvement might be to compare word length also. – Michael Durrant Mar 15 '12 at 21:29
  • **wow**, so much anger over so little. In an ideal world we should log everything. The reality (as in the real world) its just not practice, "he who has not logged a minor change, cast the first QA audit". **THIS** has nothing to do with arrogance. Put your hand up if you have logged everything (not automatic logs); if you say you have high chance your have either **forgotten** or worse **lying** – Darknight Mar 16 '12 at 10:39
  • "practical", damn 5 minute timer... – Darknight Mar 16 '12 at 10:48