I always felt strange about this, because it seemed like making big changes to the code in this way is a poor practice. Interestingly, that Peter Norvig occasionally does the same thing, and doesn't even need to understand the details of the bug in order to fix it. Here's an excerpt from Peter Seibel's excellent book Coders at Work:
Seibel: On a different topic, what are your preferred debugging techniques and tools? Print statements? Formal proofs? Symbolic debuggers?
Norvig: I think it's a mix and it depends on where I am. Sometimes I'm using an IDE that has good tracing capability and sometimes I'm just using Emacs and don't have all that. Certainly tracing and printing. And thinking. Writing smaller test cases and watching them go, and breaking the functionality down to see where the test case failed. And I've got to admit, I often end up rewriting. Sometimes I do that without ever finding the bug. I get to the point where I can just fell that it's in this part here. I'm just not very comfortable about that part. It's a mess. It really shouldn't be that way. Rather than tweak it a little bit at a time, I'll just throw away a couple hundred lines of code, rewrite it from scratch, and often the bug is gone.
Sometimes I feel guilty about that. Is that a failure on my part? I didn't understand what the bug was. I didn't find the bug. I just dropped a bomb on the house and blew up all the bugs and built a new house. In some sense, the bug eluded me. But if it becomes the right solution, maybe it's OK. You've done it faster than you would have by finding it.
This is a really smart way to think about debugging. We don't have infinite time to understand the minute details of some mistake made in the past. What's important is to get things working as quickly as possible. As long as the code has the desired functionality and passes tests appropriately, sometimes rewriting big chunks of code can be an effective debugging method.