undefined | Better HN

0 pointsnerdy9y ago0 comments

>#66 I truly do not understand the objection you are making here. If an event goes unobserved and is without impact it is the same as if the event never occurred.

#66 says: "If no one ever finds out about the bug then the bug never existed in the first place."

While the outcome is the same, it doesn't literally mean the bug never existed. The existence of a bug is orthogonal to its discovery. Its discovery does not bring about its existence.

Do you have any data for #93? I'd expect a power log distribution.

0 comments

3 comments · 1 top-level

Textarcana9y ago· 2 in thread

> discovery does not bring about its existence.

I would argue that it does but this is a matter for phenomenologists. The practical result is that it's as if the bug never existed. Beyond that let's agree to disagree.

#93 No hard data. How would you even begin to measure such a thing? No two software shops are the same, hell no two projects within the same team are anywhere similar. How to baseline? What about the impossibility of a control group for a software team?

I find it interesting that a power log distribution would result in the kind of behavior I am describing: relatively small impact for even fairly large variations in the number of tests applied to a project.

nerdyOP9y ago

If a customer discovers a bug, who created it?

Textarcana9y ago

"who created it" implies a causal chain of events whereby someone is responsible for the bug. This is Safety-I thinking. John Allspaw addresses this when he states that "there is no root cause" for an incident or bug. So in a very practical sense YES the bug is "born" at the moment the user "discovers" it. Note that "discovery" here is in the imperial sense where the the user has drawn a line on the software map (so to speak) an labeled it: beyond this here be bugs. Devops very directly implies skepticism for causality as a primary/default phenomenology for understanding bugs.

j / k navigate · click thread line to collapse