How to perform brute force troubleshooting in Ursa Studio

Sometimes you can look at an error message, performance problem, or some unexpected result data, think about the situation for a minute, and just generate a good hypothesis for what the root cause of the problem is. But usually you can’t, in which case you may need to use “brute force” troubleshooting.

The idea is simple: clone the object or measure with the problem, then modify it until you no longer experience the problem, then painstakingly work your way back to the broken version, introducing one variable at a time, until you discover which step was the breaking step.

(A common experience in data analytic work is that some process worked fine for a while, and then a bunch of things changed and now it’s broken. That’s a perfect setup for brute force troubleshooting. Just go back to the version immediately before all those changes were made, confirm that it still works under those circumstances, and then start adding back in the changes, one at a time, testing at each step, until you find the change that introduced the problem.)

The point of the brute force approach is to isolate the root cause of the problem. This doesn’t yet solve the problem, but isolating the breaking step often makes it much easier to generate candidate solutions targeted at that step.

The great advantage of the brute force approach is that it’s largely mindless, so you don’t have to wait for some thunderbolt of insight to get started. Just jump in! After crudely removing as much complexity as you think will be necessary to get back to a working version, you just robotically reapply that all that complexity, one variable at a time. Keep a log of each step, but otherwise just relax – turn on some music, make yourself some tea – you’ll hit the problem eventually.