4 ms·

One effective way of dealing with a slow bug (or "heisenbug") is to rewrite the system. That sounds crazy, and perhaps it is crazy in a company environment. B

One effective way of dealing with a slow bug (or "heisenbug") is to rewrite the system. That sounds crazy, and perhaps it is crazy in a company environment. But when I was first learning to program, I kept introducing heisenbugs once every couple weeks or so. After spending 30 minutes trying to debug it, simply deleting the entire module and rewriting it was unreasonably effective. The total time investment was about 60 minutes. I haven't encountered a heisenbug in a long time though. Maybe years. I'd like to think heisenbugs are inversely proportional to skill, but maybe it's just luck.

fest 12y ago
While that could work for small software systems (or small modules which you can rewrite), it's simply not viable solution for hardware bugs (like the one GP described) or large software projects which are mostly in the state of perpetual mess and horrible dependency graph. This actually reminds me a type of bug every electronics novice has seen- a circuit does not work unless you touch it with your finger (or even place your finger next to circuit). Some of these bugs you can solve by rewriting the software (enable internal pullup/pulldown resistor) but some others you can't solve without soldering iron (missing GND connection).
rectang 12y ago
> I'd like to think heisenbugs are inversely proportional to skill, but maybe it's just luck. Definitely some fraction of heisenbugs can be avoided through defensive programming techniques and adherence to best practices. For example, avoiding mutable global variables reduces the potential for unexpected coupling between modules when they are combined into a larger system. Similarly, limiting concurrency to the smallest possible surface area of the codebase helps a system withstand increasingly chaotic real-world input. Aggressive injection of randomness into unit tests (using proper random seeding) can also help to detect potential heisenbugs early.

fest 12y ago

While that could work for small software systems (or small modules which you can rewrite), it's simply not viable solution for hardware bugs (like the one GP described) or large software projects which are mostly in the state of perpetual mess and horrible dependency graph. This actually reminds me a type of bug every electronics novice has seen- a circuit does not work unless you touch it with your finger (or even place your finger next to circuit). Some of these bugs you can solve by rewriting the software (enable internal pullup/pulldown resistor) but some others you can't solve without soldering iron (missing GND connection).

rectang 12y ago

> I'd like to think heisenbugs are inversely proportional to skill, but maybe it's just luck. Definitely some fraction of heisenbugs can be avoided through defensive programming techniques and adherence to best practices. For example, avoiding mutable global variables reduces the potential for unexpected coupling between modules when they are combined into a larger system. Similarly, limiting concurrency to the smallest possible surface area of the codebase helps a system withstand increasingly chaotic real-world input. Aggressive injection of randomness into unit tests (using proper random seeding) can also help to detect potential heisenbugs early.