Half Splitting, Applying A Troubleshooting Technique To Debugging Code.

Recently I was talking to a friend of mine about his new job. We were talking about problem solving and more specifically about problems where you don’t actually know the cause of the problem! So we got onto to troubleshooting methods, where troubleshooting is searching for the source of a problem, so that you can then solve it.

For many programmers this idea should be painfully familiar.

My friend is not a programmer, and he told me about an approach to problem solving he’d been using at his work called Half Splitting Troubleshooting. The basic idea behind this method can be explained by looking at the following example;

“I’m thinking of a number from 0–1000, you can only ask me yes or no questions. What questions do you ask me to find out the number I’m thinking of?”

So the obvious solution to this problem is you start by saying is it larger than 500? Yes, well is it larger than 750? No, Well is it larger than 625? et cetera, et cetera….

This way you are always guaranteed to solve this problem in 10 questions. You split the possible locations for the solution in half and keep doing so until the solution has been found.

This is the basic idea for half splitting troubleshooting: You take a problem with an unknown cause and narrow down that cause by splitting up the problem. Constantly asking does the issue occur before this point until eventually you find the spot where the issue occurs after but not before.

This works incredibly well for things like finding issues on a production line or finding inefficiencies in a workflow.

I would argue it can be equally as useful in debugging.

You can apply half splitting to trouble shoot code, by using logs and break points to check whether an issue is occurring before a certain point and then placing new logs and breakpoints further along or earlier in your program depending on the information you get. The key is to have single starting point and then work from there, rather than several points you are looking into at once at different places in your code.

I’m sure many of you have done something like this at some point, and probably not given it a second thought, but one of the things I have tried to do is be more conscious of the way I approach troubleshooting.

One of the biggest time wasters I find when debugging code is that I become fixated on what I think is the cause of the problem. I will spend hours tinkering and single stepping through a specific area of my code, only to find that the problem was actually somewhere else entirely.

I have found that using a bit more of a defined and structured method to finding the cause of problems has helped me to be much better at not fixating on where I think the issue is occurring.

The idea I like behind using half splitting troubleshooting in debugging is that it creates a formal approach to what many of us already do. It forces you to be a little unnecessarily thorough and slow in your search, to help you catch the unexpected.

It means that rather than just adding breakpoints and print statements at points in your code you think may be causing the issues, you have a specific method for moving forward from your chosen start point. You know at each step of the debugging process where to look next, based on the information you have already gathered.

Until eventually you find something that’s broken, fix it. Then start the process again, until you no longer see the problem anywhere.

In Conclusion…

Half splitting troubleshooting is nothing revolutionary, and for many coders it’s probably something you have used before without even knowing it and you could even argue it is overkill for a lot of instances.

Though what I will say is I find it an incredibly useful approach to take in debugging procedural programs where the cause of the issue I’m seeing is completely unknown.

If nothing else, it is very useful to have a structured approach and a simple method to use when all else is failing!