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.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers
5

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.

That is a good point. In general case, there must be something wrong with the logic: "I am a afraid to fix a bug because I might introduce another one". A good unit test coverage would make this unlikely, but ... we do not have unit tests :) for this.
–
Hamish GrubijanJun 23 '10 at 17:23

@Hamish: It's quite common though I think. As example, if you look at any MS blog where they talk about getting any product ready for release they often talk about the different stages where a bug has to be critical enough for it to be fixed. So it's not that they don't have time (it might only take a few minutes) but they worry about introducing new errors.
–
Hans OlssonJun 23 '10 at 17:48

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.

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.

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.