[Textarcana]

Wow. Thanks for the detailed response. I will try to answer point by point.

#2 that tight coupling can ever be good comes as a shock to the learner

#3 any breakage is an opportunity learn from and about failure — also when it's broken and you know that is better than if it's broken and you don't know

Regarding regression testing: writing tests is a design activity so if it is "driven" by whatever happened to break last, that sounds like treating the symptom not the underlying cause. That is why I have never been a fan of "bug-driven development" nor of large-scale regression testing.

#20 "who draws the lines" is an incredibly important political question. So who makes the declaration that the so-called black box can not or is not to be opened? This was my point. I understand what a black box means in software testing parlance.

#31 check out this great article then: https://blogs.msdn.microsoft.com/larryosterman/2004/03/30/on...

#51 testing is runnable documentation and sufficiently advanced monitoring, particularly ubiquitous StatsD usage, is indistinguishable in practice from testing, see https://www.youtube.com/watch?v=uSo8i1N18oc

#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.

#83 no bugs always cluster at the interfaces between components

#84 Uh oh. I need to check my math and will respond further in another comment once I do so. Thanks!

#93 It's not that testing doesn't help. It's that if you have X amount of testing and you add Y amount of additional testing, THAT is not correlated with better quality. Likewise if for Reasons you do less testing in the future than you do right now, that is not guaranteed to degrade your quality.

[nerdy]

>#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.

[Textarcana]

> 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.

[nerdy]

If a customer discovers a bug, who created it?

[Textarcana]

"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.