Why even bother debugging?

Debugging systems of any kind sucks. It’s a time consuming process with very little reward. There are no heroes in the eyes of the clients or designers. Fixing a bug usually just puts you back at par. So why do it? You generally don’t have a choice! All the applications we use are somewhat unstable, whether it’s TouchDesigner, openFrameworks, Processing, vvvv, Resolume, or anything! It’s the nature of immersive design and interactive technologies. They’re new, shiny, expensive, sold to a small number of people, and sometimes don’t get as much testing love before they’re sold. We’re often left with amazing new tools that require some elbow grease. These tools get added into larger systems with complex connections and then sold to clients as the latest and greatest. How could you not find some bugs, issues, or crash states in that scenario??

Most of nVoid and zero11zero’s installations are permanent and I’ve had more than a handful of support calls and debugging sessions. I thought I’d share some of my strategies when it comes to debugging systems as our field is full of different disciplines.

Don’t find this issue

A common mistake in debugging is that you hunt for this issue instead of the issue. This strategy of debugging the immediate bug may not be a problem on smaller projects or tech demos. Larger projects and complicated systems require that you look past the immediate moment and gaze into the abyss a bit. These projects are often not turned around in a month and then walked away from. They need content updates, new features added, multiple developers, or any number of other things that may reintroduce your bug in some variation. It might be great if you solved this bug of yours quickly, but if you didn’t find the underlying cause of the bug, then it’s only a countdown till the next time it reappears. I always recommend finding other ways to recreate your issue – thus the next point.

Find new ways of breaking it

This one makes the least sense when you tell your clients you need more time to crash the system before fixing the issue. Finding new ways to break or crash your system ensures that you’ve approached the bug from all angles and that you’ve actually correctly identified the bug. Bugs and crash states are strange things. They often go from 0-100 very quickly, leaving little time to analyze the changes. Bugs can often impact large parts of a system simultaneously and hide in unlikely places. They can also be low level issues, such as driver issues, that manifest themselves completely randomly once a certain threshold condition is passed. If you accept the first appearance of your bug as it’s final form, you’ll waste time fixing your code repeatedly to fix your bug to no avail.

Take command of a bug when you find it. Consider your application or system as only a single way of reproducing it and not the only way to reproduce it. You’ll find one of two things will happen by creating test cases that reproduce the bug with different methods:

1. Your original analysis of the bug was incorrect. Creating test cases can turn your bug into just a small visible portion of a larger bug. These chains can become deep but won’t become visible without trying different ways of recreating the bug.
2. You may accidentally fix it. Test cases are simpler than your full on system by nature. Since you’re creating another version of your work, you’re often strapped on time and start chucking away things that aren’t necessarily related to the issue. You’ll approach a simpler system that is going to be much easier to debug and you may quickly come to a solution without expecting it. Nothing is better than happy accidents.

Confirm your control

A scientific “control” is the part of an experiment that doesn’t change. It’s the part of the experiment you constantly compare your results against. In debugging, I’m using control to denote our reproducible bug. Make sure what you’re debugging actually happens consistently. This may sound annoying because your first thought is usually about how to fix your thing, not getting really good at making your thing break. You may not want the crash to happen because you’re working in a public space or it might be embarassing. You need to put all that behind you and you need to become an expert at reproducing your crash situation.

The faster that you can reproduce your bug, the faster you can actually test your solutions and really confirm that you’ve fixed it. You should always test your bug on different hardware. Sometimes our specific hardware combinations can cause issues that you’ll only discover by trying to reproduce your bug on different hardware.

I see the opposite in a lot of younger developers when they’re debugging systems. They find a bug and they immediately change something in the code to “fix” the situation and get that sense of instant gratification and everyone high fives and the designers feel good about their programmer choices. Listen, there’s nothing wrong with that, we’ve all been there. What you should do when you find a bug is dig deeper and pour some vinegar on the wound even if it’s uncomfortable and takes up some more development time. Designers might bug you on why it’s taking so long, but it’s the price to pay for stability and thoroughness. It’s far better to do this than to just slap a band-aid on it and hope it doesn’t get infected later.

Rule out the obvious first

Jiggle the cable is a classic troubleshooting strategy. People think I’m joking when it’s the first thing I suggest. You’d be surprised how easily cables or hardware becomes unseated or loose. Put jiggling cables aside for a moment and consider larger issues. The common response I’ve seen to bugs is almost akin to conspiracy theories. A 15-step Mouse Trap-esque fix with a lot of moving parts and additions. I think it’s important to think through these kinds of responses and be aware of all the possible fixes you can implement but don’t be afraid to try the simple stuff that will only really take a few minutes. You might be surprised with the results.

Side tip: the professional way of saying Jiggle the cable is: “Can you please try re-seating the cable?”

Google it!

Duh, right? Most hardware and software tools & products have some form of error code system. They give us patterns of flashes or beeps, error code numbers, error message types in pop-up windows, or log or dump files that get created. These can be your saving grace. The range of information you’ll get from error codes vary from very specific/helpful to “why did you even bother making that an error code!?” but they’re still worth checking. They may end up confirming your existing beliefs (who doesn’t like that?) or giving you some hints about possible directions to explore.

Another useful element of web searches are all the other individuals out there who may have experienced the problem you’re facing. They’ve all been through the same motions as you and there’s no reason to ignore their struggle. Even in the banter of Internet forums you can find new solutions to your bug. I’ve experienced that first hand. You find a forum post from someone with a similar issue, read all the responses, and lucky you – some random person says in passing they fixed it by doing XYZ. Boom! Done! You may have just saved yourself hours or days of trial and error by doing a small Google search.

Debugging take away

There are a lot of different ways to approach debugging. No one way is particularly better than the other. The goal of this post is to expand your tool kit and give you some new ways of dealing with crisis. My receding hairline can attest to the countless nights I’ve spent trying to figure out why something crashes or breaks for no reason. Use all the tools at your disposal and don’t be afraid to try something new. The best piece of advice that isn’t contained above may be the most important: take a deep breath before starting.