views:

252

answers:

8

... that you've never seen before. But at the moment, you are are focused on task X, and you really don't want to believe what you've just seen, so you let yourself believe that the crash/problem was just some random fluke. And then you forget all about it. Weeks or months later as your app gets wider usage and that fluky thing you say gets reported. You are forced to admit to yourself that you knew, you really knew, about the problem long ago, that you had seen it with your own eyes. But wishful thinking and denial made you [mentally] sweep it under the rug.

Or is this just me?

So, how do you combat denial?

+16  A: 

By not denying! Make a note of it somewhere (ideally in some form of bug tracking software).

I tend to maintain a list of bugs marked with WATCH in their name on my projects where I collect eroneous errors / glitches. When a new one emerges (or every once in a while when I have some quiet time) I go through them and try and provoke them again.

You can waste a lot of time if you go after every glitch you come across, but by keeping a record of them, you can at least try to stay on top of things :-)

Jon Cage
This is the key! I use a stub project in BaseCamp for this right now, as I don't have a bug tracking system setup.....yet
Mitchel Sellers
ROFL Corey writes an open source bugtracker. ;-)
Dave Markle
@Dave - I'm still human though...
Corey Trager
A: 

As a mere developer, I would take it to my project lead and let them deal with it (reschedule?).

As a project lead, it depends on the actual situation. If it is as bad as described in the question, then the customer needs to know, the architecture might need changing and maybe the whole project must be started over or cancelled. It really depends on the severity.

If it is "only" a bug, then as previously stated: enter into bug tracking software and deal with it as soon as possible.

HS
+4  A: 

If I find such a bug I do the following.

  • See if I can reproduce it in 5 minutes, if so write a small test case so that you'll not lose it.
  • If I can't reproduce it in a small amount of time, I write it down where I think the problem is and make sure to start on the "hunt" for the bug a s soon as possible.

What I've experienced is that you should better try to get the bugs out as early as possible. The problem is that sometimes your debugging your current problem and after an hour of work you notice it's due to the bug you left behind because you didn't feel up for it.

So actually never dismiss something just because you don't feel like fixing it right now (because it's going to bite you when you least expect).

Davy Landman
Basically you are saying, if you can't duplicate it, and you can't find a possible cause (Heisen-bugs) you have to try harder. And if you decide that it's just not worth trying to hunt down, you're lazy.How many hours do you dedicate to Heisen-bugs? 10? 20? 40? A year?Document it and move on.
CodeSlave
@CodeSlave: in my experience I've never found a bug which could not be duplicated/located. Agreed, it can take some while, and if it would take more than a day I would certainly talk the my manager if it's wise to really dig in or just document my suspicion of the source and keep it for later.
Davy Landman
Also, if you look at the article: http://en.wikipedia.org/wiki/Unusual_software_bug which lists the Heisen-bug, it explains that they are not impossible bugs, just harder to find. Using a consistent system (and who know how many debug/mon tools), you could eventually point to the location.
Davy Landman
If you have the location (could be way off due to a corrupted pointer write), you can start looking for the cause/condition which triggers it. I've had my share of unusual bugs (pointers and c (* to less..), but in my opinion, only if you understand a bug you can decide if you can leave it there..
Davy Landman
A: 

Proper QA procedures (having someone else test the product and asses the bug importance) should prevent you to release a software containing problem like this.

As for how to track such tasks, any bug tracking software should do, but then again, you need to have a QA procedures in place, so that you do not release a product which contains bugs which are considered to make the product unshippable.

Suma
I agree with this, so long as you're not implying that the developer should depend on QA to find the bug independently. He should at least let them know.
PeterAllenWebb
A: 

More often than not, it would be just a small bug that the unit test suite didn't notice. This is what I do:

  • Open a bug for the QA team to write a test to cover that scenario.
  • Look into the source code an fix it.(if it is a small bug).
  • If it is a major bug, let your team and pm know about it. You need to account for the time you spend on fixing it.
  • Send a note to everyone involved in the project, in case they have something failing due to your faulty code.
Sridhar Iyer
A: 

This mantra: There is no voodoo in programming.

eyelidlessness
A: 

Never penalize a QA or developer for spending time investigating mysterious bugs. Do not ridicule or brush off individuals who come up with weird bug descriptions, or have weird "hunches" about your software.

Also, have a way of handling unsolved/unreproducible bugs in your bug database, and make sure someone in QA spends some quality time with those before the release.

9 times out of 10, it's going to be wasted time. But that 1 in 10 chance where that hunch lets you catch an ugly bug that would otherwise blow up in the customer's face makes it all worth it.

Kena
A: 

Never underestimate the power of denial. It is almost as bad as guilt. They often go hand in hand.

One of these days I am going to illustrate this fact in my own comic strip with Denial Man and his sidekick, Guilt Boy.

If you can overcome your own urges to feel guilty, and to be in denial, then you win.

tkotitan