Specifically for social sciences, wouldn't this mechanic be able to be exploited in the same way p-values are?

In the case of software testing, I think I agree with Dijkstra on this one, except for different reasons:

> We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).

I don't think 'blame' is the right word, or calling the 'programmer' who made the error intellectually dishonest. A fuzzy 'language' might be helpful for 'developers' who are not quite developers. A developer would categorize such an occurrence in discrete terminology - WARNING, ERROR, INFO, DEBUG, coupled with checks and tests throughout the code - in order to retain discrete structure across code, which is much easier to reason about mathematically (and much easier to isolate the source of an error), when such discrete objects and discrete structures stack.

The problem is you still need these structures in the code. You still need to include the tests in the code. You still need to know what to look for, in the code. You still need to know where the code might change, before you know where the code has changed. I don't think it's a futile effort, but I suppose I'm scratching my head a little on how this solves the problem? It's much simpler to deal with a compilation error, or any kind of explicit error that prevents some aspect of the program from running in a way that is defined as invalid. It's annoying, but it at least says "definitely broken code", instead of "maybe broken code?" which may run for a very long time, accumulating "maybe errors?". IMHO, that behavior can be perverted quite easily, because, some "maybe errors" can be ignored, other "maybe errors" can be focused on, depending on who is looking, and who isn't.

I honestly think if social scientists are going to complain about code, they need to learn how to code. A computer isn't a magic fantasy box that just confirms beliefs. It takes effort, skill, hard work, and honestly, dealing with bugs you can't always determine the origin of is very humbling (you, other developer?), so they should learn some of that too. And I'm sure they'd say "we already do!" but there we are again, going full circle, choosing to believe what we can't prove, but tricking ourselves into finding a magical way to prove what we wanted to prove, about ourselves, about others, etc. Bugs will happen. It's better when they are clearly defined, because at least the source of the error can be isolated, tested, identified, and corrected. Stacks on stacks of 'maybe error?' can lead to it literally conveying information that is the opposite of what it intends to.

There needs to be some compassion for people who are developers. We can't know where all the bugs are all the time. The best we can do is make code as bug-free as we possibly can. Coding is just hard! You think you get better at it over time, but it's really easy to be chugging along, coding coding coding, and all of a sudden - bug you didn't think of! And that just, it's humbling - and you know - this is your life, this is the path you chose. This is what you will be doing until you stop coding. Social scientists need to be nicer to developers. Same problems they deal with, just shifted.

> Testing shows the presence, not the absence of bugs (Dijkstra)