Debugging technique: Divide and Conquer

Sometimes bugs sneak into applications, and nobody notices at first. A bug is reported, and when you go back a few versions, it’s still there.

Wouldn’t it be nice to know exactly when it was introduced? You could look over the commits in that time frame, which seriously narrows down the scope of the investigation.

But what if there are a lot of versions to sift through? It’s easy to get stuck syncing and building and testing, building and testing. Each cycle takes time, so how do you reduce the overall total of these until you find the breaking change?

Take a page out from data searching algorithms: divide and conquer (binary search).

1. Sync back far enough and verify the bug isn’t present for some version. Your range is from here to the latest version.
2. Sync and check the halfway point version in your range
   1. If the bug isn’t present, your new range start is this point. Repeat #2
   2. If the bug is present, your range end is now this point. Repeat #2

You get the idea. Depending on your setup you could use git-bisect.