8

Possible Duplicate:
Should developers enter bugs into the bug tracking system?
Should I log trivial fixes?

For a project I'll be doing in school soon I will be working with 6 other people. We will probably be using YouTrack to track our bugs and we can obviously see the value in this system.

My question, however, is whether a bug should always be entered in the bug tracking system. In our case, some people will be front-end developers, others will be back-end developers but the complexity of the project will not be of such a high level that back-end developers wouldn't know how to solve a front end bug. By this I don't mean that they will actually solve it but because they (think) they know it's an easy fix, what's stopping them from just letting one of the front-end developers know about the bug by telling him across the table.

The main reasons I can come up with are these:

  • The bug might at first seem very easy to fix but actually uncover a far larger problem (at this point in time presumably it would be entered, but by the frond-end developer.
  • You might take someone of out of the "zone" by just casually mentioning they have a bug somewhere, which might be solved in 10 seconds but then requires them 15 minutes to get back in the zone.

On the other hand it does seem silly that you'd have to enter a bug which could be fixed in 2 minutes, especially if the part you're working on at the time needs that bug to be fixed.

I understand this is probably a bit subjective, but I also feel that other people could give very good reasons for doing it one way or the other which is what I would like to hear.

Community
  • 1
Mekswoll
  • 361
  • 2
  • 11
  • 2
    If you commit a fix for something, it should generally have a corresponding bug unless it's _extremely_ trivial and the diff itself in its own context is sufficient to explain why the code was changed. – Tim Post Jan 10 '13 at 23:29
  • 1
    Related - http://programmers.stackexchange.com/questions/136629/should-developers-enter-bugs-into-the-bug-tracking-system?rq=1 – ChrisF Jan 10 '13 at 23:34
  • 2
    for some of us this would be required due to safety requirements – jk. Jan 11 '13 at 09:13
  • 1
    Related - http://programmers.stackexchange.com/questions/139893/should-i-log-trivial-fixes – Philip Jan 11 '13 at 21:55

5 Answers5

17

More important than filing a bug report is to create a test case that will trigger it.

If it takes only two minutes to fix a bug, how quickly would you forget about it?

Create that test, fix the bug, and it won't raise its ugly head again.

The test case is a living bug report, in the sense that no-one has to browse through a bugs database to evaluate what might need attention.

See also this inspiring lightning talk by Jon Arild Torresdal: Why you shouldn't track bugs

Both @Karl and @Andrew mention an important caveat: After code is released, any bugs that are not (easily) fixed are now part of the product, and should be documented.

Henk Langeveld
  • 348
  • 2
  • 10
11

At school, I guess it doesn't matter so much...

But out in the big-wide world then without a doubt you should record the bug. There are a number of reasons for this.

  1. Once code has been released, changes should only be made for traceable reasons. This is especially appropriate in regulated industries (aerospace, medical etc) where type approval includes software audits.
  2. It means that the code-change is traceable through the whole lifecycle - particularly testing and release documentation. eg in a project you'll also want to extend the test spec
  3. It may not actually be a bug - you may have misunderstood, or maybe it'swhat the customer wants
  4. It ensures that only one person is trying to fix the bug
  5. It ensures management visibility - when asked why you haven't finished what you SHOULD have been doing, you can show what you HAVE been doing
  6. Doing it properly reduces the risk of accidentally adding in a different (bigger?) bug
  7. There is the chance that the cause of the original bug leads developers to learn lessons
  8. etc
Andrew
  • 2,018
  • 2
  • 16
  • 27
6

For last 10+ years I always use bug reports in cases like you describe.

Thing worth keeping in mind is that with sufficient practice, this will take you very little time and effort (that's a matter of fluency).

Another important thing to consider is that using bug tracking should be convenient. Purpose of bug tracking system is to make developer more productive, not less. If it's easier to achieve the same goal without bug tracking tool than with it, this kind of trashes purpose of the tool.

  • To be precise, it can be somewhat cumbersome at first, when you are getting used to the tool, but if after substantial practice it still doesn't feel easy, this indicates there's something wrong - either with the tool, or with the way you use it, or with the way how bug tracking process is set up in your team.

Taking into account how important is the convenience, have to note that one thing in the title of your question feels really slippery: "always enter a bug".

This appears to assume a new bug report has to be always created - a typical newbie mistake; I made this mistake myself, it gave me quite some pain and it took a while to figure this ain't necessarily so.

It could be sometimes more convenient to just add the bug you discovered to some existing report, or, if you found several bugs, list them in a single report.

  • In one of the past projects I was assigned to fix issues discovered in code review performed against particular component. Review document listed about 180 (one hundred eighty) items; I sure as hell was going to use bug tracker because I knew it'll be a nightmare to track work progress otherwise.
     
    But I was not going to create 180 separate bug reports either (why would I?) - I just created one for the whole list bug report #123 address code review comments submitted 20.10.2010 against component XYZ.
     
    In the course of my work, some of the items turned out to be worthy dedicated bug reports; no problem I created these when needed. "Progress table" in bug #123 looked about as follows 

    review item  status
-------------------
item 1       fixed
...
item 11      not started
...
item 21      in progress
...
item 31      extracted to bug report id #234
...

it does seem silly that you'd have to enter a bug which could be fixed in 2 minutes

Silliness here depends on how much time does it take you to register the bug you discovered.

  • If it takes say, half an hour, it's definitely silly. If it takes 5-10 minutes, it's not too smart but may be OK if happens infrequently. Finally, if it takes less than a minute, why not - I see nothing silly here.

Actually, in cases like that it just takes me less than a minute, and here's why. Look, here's what you have

the part you're working on at the time needs that bug to be fixed

As for me, the part I am working on is always registered in the issue tracker. When I find a 2-minute-bug needed to be fixed for that part, I just add a comment in the bug report I am working on, like

discovered and fixed <this bug>

Heck I do this even if the fix isn't needed right now. Why wouldn't I?

Community
  • 1
gnat
  • 21,442
  • 29
  • 112
  • 288
  • 2
    Well said, if logging a bug is an onerous consumption of time, the answer is to make it not so; not to avoid logging bugs. – Carson63000 Jan 11 '13 at 20:46
  • You wouldn't because when someone now or in the future does code review and checks the requirements or expectations against the code, it will be made harder if some of the code change is not about the actual issue being addressed. So log a separate ticket for it. – Michael Durrant Jan 11 '13 at 23:52
  • @MichaelDurrant good observation: that _harder_ part is for real. One thing is to look at the code change comment, find bug Id, open bug tracker and find the idea right there, in bug summary. Quite another is when in addition to this, one has to read through whole bug report to find the comment describing the change. In my "story about 180 items" I was considering just this when deciding on items worthy extraction to "dedicated bug reports" – gnat Jan 12 '13 at 05:58
2

You generally don't need a bug report unless a version of software with the bug exists outside of your development team. If you don't need one, you might still want one if there's a chance you might forget about it before getting around to fixing it. For me that means if I haven't fixed it by the end of the day, and it's not in a file I currently have checked out for other reasons.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
1

A paper trail can be useful to cover your ass if things go tits-up and management start asking questions. An official bug will have the details of the bug, the name of the person who fixes it, the names of the people who reviewed it and a way of identifying the actual source code changes.

Managers love processes, it's a good idea to follow them.

James
  • 4,328
  • 3
  • 21
  • 25