Fix First, Think Later

Here's something I sometimes do when hunting a bug that requires me to get to know a section of code that I'm not yet familiar with.

I find a quick and crude fix first. I look at one function, where I guess the problem might be, and tweak something, add an offset to an x- coordinate, or a scale factor, or overwrite a variable with a constant I know will work in one certain situation.

After the fix is working -- maybe only for one certain narrowly-defined situation -- I start to look at the under-the-hood stuff in the code, like where the x-coordinate is calculated, or where the variable goes after I modify it, and work my way into the code until I understand it well enough to know

1) why my crude fix worked, and
2) what I have to do to fix the problem for good, so that it works for all situations.

Sometimes I iterate this process, after understanding a little of the code I am studying, I take out the first crude fix, and put in a second, more refined one, even though I still don't fully comprehend the workings of the code.

I sometimes wonder if this is the right way to go.

Working like this takes up more time than just sitting down and studying the code until I fully understand what it's supposed to do, and why it doesn't. On the other hand, working in small steps gives me little successes one by one, which keep me motivated. I wonder if I'm just doing it this way to make a tedious task less boring.

And wondering that, I'm not sure if that's not all right to do, to keep yourself motivated, instead of laboriously chewing your way through boring code.

I also like to think it gives me a better 'feel' for the code, having 'experienced' the workings of it by getting my hands inside it.

What do you think?