Nick Mudge Ignition Software Consulting & Development

I kind of realized for myself how to debug software. The bug will be at the very end of where a program is working correctly. So one merely needs to test the execution of code from the beginning of execution going forward until one finds an error. I've often said, "follow the logic". By this I mean test or examine the code from the beginning of execution until you find the error.

So this is how a person could debug:
Find the very start of execution of the code. Test the execution of the code from the beginning going forward. One could test the beginning of the execution, and then a little more of the execution, and a little more of the execution, until an error occurs. Before you give up trying to find an error, throw out all your guesses and assumptions and test everything.

A faster way to find an error when you have no idea where it is, could be like this:
Find the midway point of the code that executes. Test the first half of the executing code all at once by only running or testing this first half of the code. If no error occurs, then the error doesn't lie or manifest in the first half of the code.

Now you have the second half of code. Cut the second half of the code in half. Now test the first half of this code. If this code works, then you know the error lies in the second half. So cut this second half in half and test this first half and so on. The whole idea is to zero in on the bug by eliminating code that you know works. When you find a code half that doesn't work, then cut that half in half and test the first half and so on until you find the exact bug.

This halving of code method is the same idea of the best way to guess a number out of 100. You guess 50 and someone tells you if the number is higher or lower than that. If the number is higher, then you guess 75, if the number is lower, then you guess 25. You continue cutting the numbers in half until you get the right number. If you were guessing a number out of a million, it would only take you 20 or less guesses to get the right number every time.

The best method I have found of finding a bug is to eliminate working code so that all that is left is the bug. And the bug will be at the very end of working code. The skill and imagination of locating a bug in this way is figuring out how to cut your code in half and get your code reporting to you the right kind of errors. In my experience, there have always been ways of getting code to report to you errors.

This method of locating a bug is also a good method of finding a bottleneck when there is a performance problem. Time the first half of code and then second half of code. Take the slower half of code and cut it in half and time those halves to find the slower half and so on.


15 January 2009

Theres a research group at

that takes this approach to extremes. They can automate the whole process, including replaying calls between objects to find bugs in linked code.
16 January 2009

As for finding bottle necks, the easiest way is to often fire up a profiling tool for your environment.
Name: (required)
Email: (required)
What has four legs, rhymes with bat and says, "Meow?" (One word answer.)
Spam Filter: