Bugs are great. The programmer gets paid to develop software, but what would life be if there were no errors one could fix in the next release? The security professionals, both the ‘black hat’ and the ‘white hat’ guys, make a living out of unforeseen application behavior. And finally the small talk of users is nourished from the ‘funny things’ that happen using buggy software. And since bugs are so great, they even get categorized and named like the real-life bugs (those small creatures with six legs). I just recently came across the denominations Heisenbug and Bohr bug. The origin of these names being Heisenberg and Bohr already indicates their meanings. The Heisenbug is the kind of problem that vanishes if looked at more closely. Every measure taken to identify the bug makes the symptoms go away. In contrary, the Bohr bug is easily reproduced and nailed down. It’s the classical sort of bug. But what relevance have those names to the user reporting bugs? At first glance none, but since it is clear that programmers, especially those with a scarce time budget, prefer fixing Bohr bugs, each report of such a problem should include detailed instructions how to reproduce it. This means that the user is in his own interest responsible for passing all relevant information to the developer. Although this seems to be a trivial fact, most users just don’t care. Ultimately this leads to frustration, since reports about being unhappy with an application without giving details usually go to /dev/null.