While developing (either features or bug fixes) I sometimes happen to discover bugs that are not directly related to what I'm working on. What should I do in that situation. Just fix it? Try to remember to fix it later? Write it down somewhere? Or enter it into the bug tracking system?

I generally enter it into the bug tracking system and let the process play itself out (i.e. triaging, assigning, etc.). However I have hardly ever seen another developer enter a bug. (Why is that?)

Perhaps the problem is that they're thinking about it as "someone else's bug system".
–
XeoncrossFeb 23 '12 at 22:44

6

Unless there is a mandate not to, please enter it. When you check in code, it's generally a good idea to associate the check-in with a work item. On top of that, I've seen a few places where someone sees a bug, assumes it's a known issue, and never tells anyone about it. You don't want to do that.
–
JSWorkFeb 23 '12 at 22:53

4

Unless it a simple and obvious change, you should not try to fix it. By adding another moving element in your current fix, you can make things much unmanageable. You should absolutely log it so if can receive its appropriate attention. Ie. if you fix it without logging a ticket for it, the QA will not know to test it and you can potentially introduce an even larger problem. This is dangerous. Other developers may just not know any better... you should bring it up.
–
sam yiFeb 24 '12 at 4:34

16 Answers
16

If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all.

In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked.

It's possible that there might be some reason, valid or not, that developers shouldn't be entering bugs. One possible reason might be that the bug tracking system is visible to outsiders, and having too many reported bugs looks bad. That's a very bad reason, which should be addressed in some other way that still allows bugs to be tracked. Ask your boss.

(Of course if there's a bug in code that you're still working on, and it doesn't show up in anything that's been released, there's no need to track it in the system, though a TODO comment in the source code may be a good idea. To take an extreme case, "This code won't compile because I haven't yet typed the semicolon at the end of this line" is not a reportable bug.)

As for why other developers don't enter bugs, you'll need to ask them. They probably should.

Plus tracking any bugs you encounter allows you to write unit tests and do regression tests on that behavior, even if it's some simple fix. You never know when someone will go back in and break it again, and then you get deja vu when you think about why the bug feels so familiar, and then you have no bug number to reference. Not like I would know...
–
birryreeFeb 23 '12 at 20:33

3

@KeithS: If it's a bug in code you're still working on, yes, reporting it would be silly. If it's a bug that's in a released product, even if it's in code you're just about to fix, it should be reported, so there's something to refer to if, say, an end user encounters it. There's value in a bug report even if you close it immediately after opening it (though "close" typically covers several status transitions).
–
Keith ThompsonFeb 23 '12 at 23:38

2

The other thing to do is make sure that someone knows about the bug. If your team leaders view all of the new issues as they arrive, you've got this covered, but if you know that the issue won't be seen for a while, then you need to know that whoever is responsible for prioritizing work will make sure the issue will be dealt with. Your daily stand-up meeting, or your regular team meetings can be a good place to announce these things, or shoot your team leader an email if your issue tracking system doesn't already do this for you.
–
S.RobinsFeb 24 '12 at 5:28

1

@S.Robins: Yes, but if entering a bug in the tracking system doesn't make sure someone knows about it, then your tracking system isn't working very well.
–
Keith ThompsonFeb 24 '12 at 7:21

when the bug concerns the code you're not working on right now or the part on which another developer works.

This is essential, since the bug tracking system is made to... track bugs. Every bug. If you discover something wrong, don't just fix it. Document it through bug tracking system. When later, a customer running a previous version of the software will report a bug which is an exact duplicate, you will be able to link it to your report. If you have nothing to link to, you'll waste your time (or your colleague) searching for the bug in previous revisions, then try to solve it, and finally find that the bug was already magically solved.

This also explains why freelancers must use both version control and bug tracking system: those two tools are not only for teams.

You make a very good point, assuming the bug is present in a previous release.
–
Karl BielefeldtFeb 23 '12 at 20:42

2

Mmm. Not every bug surely. Say you're reading though some code you just wrote and you find an off-by-one error in a nearby loop condition, say. Or a typo. It takes longer to write the bug than it does to just fix it, especially if the code is all still in development.
–
Zan LynxFeb 23 '12 at 23:03

2

@ZanLynx In those cases you should be working on an open bug report or feature request. If it has been released to testing, reopen it and add an appropriate note.
–
BillThorFeb 23 '12 at 23:36

There is no valid reason not to enter a defect into the defect tracking system. The only places where I have seen bug fixes applied without tracking is because the process was fundamentally broken. If this is the case, fix the process.

reasons for not entering are :

The process measures and punishes based on defect reporting -don't report, don't get punished. In this case leave the organization

The process is a burden - it takes too much effort and time to enter a defect and get to the point of fixing it. The process should be changed to allow developers to fast track a lightweight bug through the triage/accept/fixed process.

Some devs are lazy/sloppy/hackers who don't care what the impact of the things they do on others might be. Recruit professional developers.

I'm a one man band, don;t see the point. Go work for a 2 man band and you will....

@phkahlr : I agree, every system has robust regression testing that ensures the perfectly specifed requirements are met and the customers never us unspecified features, The current developers write perfect code every time so there is no chance of a bug fix introducing unwanted side effcts. I this world, "just fix it" might be approrite. I my world, where theres millions of lines with limited regression tests implementing life critical legacy system, I think I'll follow a process.
–
mattnzFeb 24 '12 at 21:00

Fixing the bug right away is probably a bad idea. First, someone else might be working on the same fix, resulting in duplicated effort, and also, depending on the development methodology you're following, prioritizing what to work on next (fixing a bug or implementing a new feature) is more of a management decision then a development decision.

That assumes a large team and an environment where programmers arent making decisions. If there's only a handful of developers and you can spin your chair around and say 'hey, is anyone working on X', there's no particular reason not to fix the bug right away (if time permits).
–
GrandmasterBFeb 23 '12 at 22:25

1

@JoelFan: Flow is already interrupted. My flow would be more interrupted by knowing there was an unfixed bug.
–
Zan LynxFeb 23 '12 at 23:05

3

@GrandmasterB As we’re already talking about flow, I wouldn’t want to disturb all the other developers like that. If you encounter a bug, report it, and let the others look at it, when they get the time. That’s much better for everyone than making them stop doing what they do, just so you can explain the bug to all of them, and just to find out that probably nobody is working on it, leaving them all interrupted with no result on that bug whatsoever…
–
pokeFeb 24 '12 at 0:52

Bug tracking is essential for communication, especially on large teams. One of the best benefits of having multiple eyes on the code is the ability to detect problems earlier, and that benefit is lost if bugs are not logged or tracked as you are developing.

Often, bugs are most easily fixed while you are already in a part of the code, working to understand it.

Even on smaller teams, there is a lot of benefit to be had morale wise by being able to list bugs, and progress at fixing them - sometimes the morale benefit is crucial even on one man projects.

Accurate bug detection can be very difficult after the fact - seeing a bug in code can save a lot of later work playing detective, trying to figure out where the issue originally occurred.

It's good for your general development as a developer to pay attention to bugs as you see them, and get in the habit of improving/cleaning up/reading code critically

Logging bugs as you find them is, generally speaking, a good habit to have.

(some) CONS

Entering bugs into a bug tracking system can be onerous and time consuming, and can be really disruptive to development work - more often so when working in large teams. You may be expected to:

check if your entry is a duplicate before entering (this could even be implicit, it's discouraging to enter your bug into the queue only to have it closed)

provide repeatable test case(s) for your report

accept later interruptions with questions about bug details, to accept/verify a fix when written

think about unrelated information that is often collected in bug tracking systems, such as which product is likely most affected, the priority of the bug, etc...

Sometimes bug tracking is just not the most efficient use of your time.

These are two general principles which can be hard to balance - finding a good strategy is a bit of an art. In situations like these, I think it's best to adopt a flexible heuristic, that I tweak as required for a given project, team, work environment, and your general skills. My strategy usually follows a pattern like approximately as follows:

Always log issues as you see them throughout your day, somewhere. Maybe on a sticky, maybe in a file to the side. Maybe all you log is a file name and line number, maybe more. Don't let the problem interrupt your current line of thought too much.

Take time at the beginning of each new work-day, as part of your warm-up for work, to deal with the stickies. I take 10-15 minutes to go through my list of detected issues from the day before and do whichever of the following is quickest:

Fix the issue and commit it (probably for one liner fixes or typos). If you're not permitted to commit without a bug report, create a side-project for small commits. When enough fixes accumulate in the side project, take the few hours you need to document them and commit.

Log the issue in a bug tracking system (for obvious issues that take longer to fix, but without onerous overhead)

Log the issue in a "to look at when not busy" document (I usually add a "//TODO - this looks broken, fix it" type comment to the source). Regularly take a day (I try for once a month) to go through the list and log it as appropriate - feature request, bug report, discuss with manager, etc...

Over time, I've found all sorts of tweaks as useful. For example:

In more rigid environments, I might just offload the bug reporting work to the testing team - get a tester to meet with me for an hour every once in a while, hand them the list of issues, and get them to do the logging. In environments where logging tests is a big deal, usually the tester will be glad for the free boost to their productivity.

Some teams refuse to allow any fixes that don't have a customer bug report behind them. I'd keep a project full of fixes on the side, and instantly commit them when the relevant issue is reported by a client, for free brownie points.

Some teams require that the person "owning" a chunk of code be the one performing fixes. I'd treat the code "owner" like a testing lead and meet informally to hand off issues occasionally

I find that, generally, as you follow this type of strategy, more and more of your peers and other company members will start to respect your work, and commitment to quality. After enough time, you'll have the respect and authority required to optimize the entire process to your liking. Keep an eye out for such opportunities, and take them as appropriate.

"Some teams refuse to allow any fixes that don't have a customer bug report behind them"... really? Sounds like a DailyWTF! So you're saying there could be a clear bug, that definitely would (and possibly has) affected customers and they just keep pushing out releases with the same bug unfixed, without even analyzing the cost of fixing it, solely because a customer has not yet reported it?
–
JoelFanFeb 24 '12 at 3:25

I believe that if a developer encounters a bug that is not related to what they are working and that they will not be fixing, they should enter it into the system just to have some record of it. That way, when QA starts testing (and they're still not fixed) you can give them this list bugs as "known defects" so they don't start reporting the same bugs.

Perhaps other developers who find bugs keep track of it on their own if they plan to fix it, but in that case they run the risk of 2 developers independently finding and fixing the same bug.

Why is that? Because most developers look at the issue they have to raise and the code they have to write and figure it's easier not to bother.

But, whether that's the right thing to do depends on your process. Do you have a QA team? Do you think they mind if you just go changing code which won't be tracked? What about code-reviews? Will it skip by that crack? What about the business? Do they need to know you've fixed a bug so that they don't raise the same one later?

What about other developers? What if they fix it in a different way at the same time? What if they find a similar bug later and all you can do is say "oh, damn, I know we've had something like this before -- now what was it?"

There are about a million reasons for recording bugs in the bug-tracking system. If you're SURE you don't hit any of those issues then by all means, don't bother. But if you're at all unsure then you should record it, even if most people don't.

Programming is a complex work fundamentally. The bugs are complex. so I used to assess a bug by two factors:

How often such kind of bugs may appear again in future? Whether this estimate is accurate or not, keep estimating.

When such kind of bugs appear again, is it easy to understand? This is accurate when you analyze this bug and fix it.

I would classify a bug into one of the following types:

Likely appear again in future, and easy to understand

Likely appear again in future, but hard to understand

Rarely appear again in future, and easy to understand

Rarely appear again in future, but hard to understand

In case 1, a cookbook or FAQ is a good device for the team to fix such bugs in future.

In case 2, an elaborate and comprehensible record is the necessary for the team because it is a waste of effort if another programmer endures such bugs again. For example: memory leak.

In case 3, I think it is not a big deal that there is nothing left for record because you won't spend too much time to fix an easy bug. For example, a typo for id of element in HTML.

In case 4, such bugs create a dilemma. It needs some time to write an elaborate and comprehensible record to describe such bugs. But this record is rarely used in future. Without a record, however, appearing of such bugs would be a struggle again. For example, such bugs appear because of computer virus in somebody's computer.

Of course you should enter it. Or at least report it to your QA people if that's your normal process.

Even if you do just fix the bug yourself, you'll want a record of the change so that it can then be tested to ensure that the fix actually works and that there hasn't been a regression. It's also possible a user might report the bug at some point, and if it's in the system and marked as fixed, your support people can tell them that it's already been addressed.

Indeed you should be recording them in the system, and in case it's not practiced then it's good to start off.

In my past I was part of a product team, and we were on the beta release of a new product and at times we occasionally found bugs which at that point we used to note down and mail to the respective persons handling the modules (we had a bug tracking system, but we didn't think of pushing them there). Later on when days went by the items in the mail started to get ignored because of other priorities and that eventually lead to some sleepless nights.

Then, bang one day, Nirvana! Why are we not using the bug tracker, even if you found something which seems like a bug and could be possible that it isn't one (your thought about the process is wrong/flawed). It at least makes up on the list which could then be tested and most important of all a feedback as to why it's critical or on the flip side it is perfect and that's how it should work because of reasons 1... 2....

Now you have the list and also for those who have misunderstood some parts of the application they have the feedback based on which they can clarify their thoughts. A win-win situation.

Memory - The system is really unlikely to forget the bug, any given developer may.

Metrics - The number of bugs found, closed and the time taken can be good easy-to-capture metrics to tell you how the quality of your code is progressing

Urgency - It might seem like the most important thing in the world to the developer, however the time spent fixing this issue may be better spent on something that the end users want first (see also memory).

Duplication - Maybe it's already been spotted and is under examination / fix by someone else. Alternatively maybe it has fallen foul of the urgency rule and been put off. Of course the fact that you've found it again doesn't just mean that it shouldn't be done, it might mean that (as it keeps coming up) that is is now more urgent to fix.

Root cause analysis - The easiest bug to fix is the one that was never there. It may be that the team should be looking at this bug to find out how it came to be. This is definativley not to punish the one responsible (that never helps) but to find out how the situation can be avoided in the future.

Wider impact analysis - The cheapest bug to find is the one you knew about before you found it. By looking at this bug (particularly after doing root cause analysis) it may quickly become clear that this problem could exist in other places in the code. As a result the team can choose to go find it before it raises its ugly head at a more embarrassing moment.

The amount of time that is spent on these (if any) is largely dependent on the maturity and quality level of the code. Root cause analysis is likely to be overkill for a tiny team working on demonstration code, but a large team on business critical development probably need to learn the lessons effectively and efficiently.

From experience there are two broad reasons that developers avoid using the tool:

The bug handling tool and/or process is perceived as too heavyweight for the development

The developers find the mental challenge of fixing the bug more interesting than the stuff they are currently working on.

Item 1 implies that a better/simpler system may be required; or alternatively a more compelling justification of the existing system might be in order.

Item 2 should be a useful warning sign to the development lead about current task allocations.

I mostly agree with FrustratedWithFormsDesign but I think it is even clearer if the whole issue is broken down into two areas:

Bug Reporting.

Bug Fixing.

These are often treated as being the same and separating them will almost certainly help a lot.

These can be handled with:
Bug Reporting:- put it in the system, as everyone says.

Bug fixing:- Every week or two (adjust to your development schedule, etc.) everyone gets together on the project and decides what should be fixed, by whom, etc. This was everyone is on the same page and can see what needs to be done. In Agile Development this is the Sprint Planning meeting.

A good tool that people want to use also makes a big difference. I like Pivotal Tracker and it passed my 'really useful tool' test when I started using it just to keep track of things I want to do or fix in my own private projects!