Some time ago, I stumbled upon the term “Heisenbug.” What a perfect name for a bug! If you’re a coder, be forewarned this article may cause reminiscing on past encounters of beautifully painful bugs. I’ve added a little commentary to this Wikipedia article.
Heisenbug is a pun on the name of Werner Heisenberg, the physicist who first asserted the observer effect of quantum mechanics. Heisenbug is the classic, turn on debugging, and everything works perfectly. Turn off debugging, and bugs crawl back out.
A bohrbug, unlike Heisenbug, is a “good, solid bug.” Like the deterministic Bohr atom model, they do not change their behavior and are relatively easily detected. Compiler or linker errors are good examples of this bug. Most bohrbugs should never exist; someone slips up by not first doing a proper code submit test.
A mandelbug (named after Benoît Mandelbrot’s fractal) is a bug whose causes are so complex it defies repair, or makes its behavior appear chaotic or even non-deterministic. The term also refers to a bug that exhibits fractal behavior by revealing more bugs (the deeper a developer goes into the code to fix it, the more bugs they find). This messy code tends to be litter with copy-paste bugs spawning sporadically throughout the code. Here be dragons. The clean-up process is tedious; developers must fight their desire to rip-and-replace than refactoring.
A schrödinbug or schroedinbug (named after Erwin Schrödinger and his thought experiment) is a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place. Unfortunately, I’ve seen this bug a couple of times, working at a customer site late into the evening, waiting for a “big link” to complete to test my correction. Only to discover, nothing changed. After few more links with no observable changes, purposely add bohrbug to break the build, and yet, the code builds and links fine, then to only realize that quick hack to speed up the build time was a schrödinbug.
A hindenbug (named after the Hindenburg disaster) is a bug with catastrophic behavior. When I was a kid, and I mean a kid like a second-grade kid. I wrote a little recursion program. Unknown to me at the time, I had triggered a stack overflow on my MicroAce (a ZX80 clone – one of the first clone battles). The stack overflow damaged the video driver’s memory. The bug produced a beautiful result; the text would smoothly float up the television screen with a ghostly effect. Recursion is beautiful and dangerous.
A higgs-bugson (named for the Higgs boson particle) is a bug that is predicted to exist based upon other observed conditions (most commonly, vaguely related log entries and anecdotal user reports) but is difficult, if not impossible, to reproduce in a development or test environment. The term may also refer to a bug that is obvious in the code (mathematically proven), but which cannot be seen in execution (yet difficult or impossible to actually find in existence). The first time I saw higgs-bugson was in 2000, while working at a company building a large message bus system for enterprise and Internet-scale problems. On the server-side, the system used timers for watchdogs and scheduling messages to flow through the system. Over a weekend, the server died a horrible unexplainable death. A team dedicated to finding the bug spent days and nights hunting for this unexplainable bug. In the end, they found a timer had use local time and not GMT, so on the fateful weekend when clocks roll back an hour – the server came crashing down.
Some good news, Dellfer helps uncover all of these bugs. We do more than stop devices from being hijacked. We provide critical details for killing these bugs once and for all. Reproducing bugs is always the most significant challenge. Bugs seem to crop up at the worse times. Apply Dellfer to your code for soothing relief. Dellfer delivers instant pain relief to your aching backlog, your engineering teams’ glutes, your QA’s toes, and your supports’ burning ears.