Should unimportant bugs be fixed just so that they do not distract developers?

Question

While Joel Spolsky thinks that every bug should be fixed before new code is written, the reality in many places is that developers are very busy, and some bugs are deemed worthy while others are not. Unit testing is also often treated as nice to have.

I have been chasing a mysterious bug in a critical application, and found a few minor ones in the process. I mentioned them to the original author, and he said something like "Oh yeah ... I remember QA raised these 3 years ago but they were shut down".

I suppose some developers are better at multi-tasking at others. With me personally - I like to work on one thing at a time, and even if there is a 0.1% chance that an unimportant bug might be interacting with a serious one, I have an urge to just fix an unimportant bug first (understand it better in the process too) and not think about it later.

On one hand I would be wasting my time on what business analysts deemed not worthy. On the other - I might be able to fix the important bug faster if I can focus on just that one task.

Before I try to make this argument, I wanted to ask what your thoughts and experiences are with a situation like this. Question is marked as community wiki. Thanks.

Answer 1

This sounds like it falls under the category of "whatever works best for you and your team". If you're really that tight on schedule that you don't have time to fix the bugs, you need to have a good justification for doing it anyway.

If the bugs annoy you and stop you from focusing on bigger problems, that might be enough of a justification to do it, although you might have to explain why you missed a ship date because you spent a week fixing trivial bugs before fixing the one big bug.

Answer 2

While it's nice to think you can ship bug-free code, in reality there's always another one. That said, I think the most pragmatic approach is to rank order the ones you know about by severity and fix each as time and resources permit, prioritized by severity.

Answer 3

Joel's post clarifies the "Do you fix bugs before writing new code?" philosophy.

""zero defects" meant that at any given time, the highest priority is to eliminate bugs before writing any new code."

This explanation could use slightly more clarification, but I am able to gather that he does not mean there is an expectation of perfection, rather programmers should strive for perfection. This means a programmer should not knowingly skimp on a method implementation just to get the product out the door. A full definition of the "zero defects mindset" helps to clarify:

“A best practice or principle of a successful team, it means the project team commits to do work at the highest quality possible at the time it is being done, and each team member is individually responsible for helping achieve the desired level of quality. The zero-defect mindset does not mean that the deployed solution must be “perfect” with literally no defects; rather, it establishes perfection as a consistent goal for the team to strive for.”

Since you are going to make a recommendation to your team, keep in mind that this philosophy is a team philosophy. Trying to follow this on your own could lead to a high level of frustration in the case where your argument is not accepted by the team, but you try to follow it yourself.

Answer 4

Just remember that whenever you change code you might introduce new bugs, so by fixing those small bugs deemed to unimportant to fix, you might accidently introduce a new serious bug. Sometimes that's a risk worth taking, but on some, critical, systems you should never touch any code without good justification. So what kind of system you're working on can be an important factor for answering this question.

Answer 5

Very interesting question. Like others said, it's up to the team. Resources, deadlines, personal beliefs and much more interfere on this question.

In your case, I think the best option is to discuss this matter with your superiors and workmates. Don't take all the responsibility only for yourself.