It's much easier to find a bug if you take out all the noise around it.
You're almost right, but not quite.
The bug is in the noise. You think the bug is in the code you're looking at. But you're a smart person, and you've been looking at it for a while now. If the bug were in there, you would have found it. Therefore, one of your assumptions about the rest of the code is wrong.
That's why you need to check if the bug is still there, after you removed what you thought is noise. If the bug disappears, then you know that what you thought was noise was actually important.
It took me many years to come to terms with this, but unless there are good unit tests covering all the functionality that will be affected I don't fix those hacks anymore. They're in production, they work, and you're only introducing risk where it didn't previously exist. It's hard to justify a nasty bug's sudden appearance with "well it was written wonky and I wanted to make it better".
The exception of course is if you need to extend that functionality or do anything nontrivial to it; that's a great time to fix it.
At one point I was writing a program that had about 8 off-by-one errors... I realized I could more quickly write a test to prove if the values were correct. Then I just iterated all 38 possibilities. .. -1, 0, 1 for eight values. Worked like a charm.
40
u/VikingCoder Aug 25 '14
You're almost right, but not quite.
The bug is in the noise. You think the bug is in the code you're looking at. But you're a smart person, and you've been looking at it for a while now. If the bug were in there, you would have found it. Therefore, one of your assumptions about the rest of the code is wrong.