Gettiers in software engineering (2019)
jsomers.net
Gettiers in software engineering (2019)
1–10 of 222 posts
Re: Gettiers in software engineering (2019)
#2The link to the actual paper [1] seems to be overloaded.
Re: Gettiers in software engineering (2019)
#3Meh, these are just examples of the inability to correctly root cause issues. There is a good lesson in here about the real cause being lack of testing (the teammate’s DOM change should have never merged) and lack of monitoring (upstream mail provider failure should have been setting off alerts a long time ago).
The changes only had adjacency to the causes and that’s super common on any system that has a few core pieces of functionality.
I think the core lesson here is that if you can’t fully explain the root cause, you haven’t found the real reason, even if it seems related.
Re: Gettiers in software engineering (2019)
#4An old timer I worked with during my first internship called these kinds of issues "the law of coincidental failures" and I took it to heart.
I try a lot of obvious things when debugging to ascertain the truth. Like, does undoing my entire change fix the bug?
Re: Gettiers in software engineering (2019)
#5I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring. If you have no idea what is going on at a granular level, you’ll quickly jump to bad conclusions and waste a lot of time aka $.
Re: Gettiers in software engineering (2019)
#6An old timer I worked with during my first internship called these kinds of issues "the law of coincidental failures" and I took it to heart. I try a lot of obvious things when debugging to ascertain the truth. Like, does undoing my entire change fix the bug?
Yeah, good times. I just recently had one that was a really strong misdirection, ended up being 2 simultaneous other, non related things that conspired to make it look convincingly like my code was not doing what it was supposed to. I even wrote tests to see if I had found a corner-case compiler bug or some broken library code. I was half way through opening an issue on the library when the real culprit became apparent. It was actually a subtle bug in the testing setup combined with me errantly defining a hardware interface on an ancient protocol as an HREG instead of an IREG, which just so happened to work fine until it created a callback loop inside the library through some kind of stack smashing or wayward pointer. I was really starting to doubt my sanity on this one.
Re: Gettiers in software engineering (2019)
#7Hmm, are there better cases that disprove JTB? Couldn't one argue that the reliance on a view that can't tell papermache from a cow is simply not a justified belief?
Is the crux of the argument that justification is an arbitrary line and ultimately insufficient?
Re: Gettiers in software engineering (2019)
#8I usually just call these red herrings: https://en.wikipedia.org/wiki/Red_herring
Re: Gettiers in software engineering (2019)
#9“I am sitting with a philosopher in the garden; he says again and again 'I know that that’s a tree', pointing to a tree that is near us. Someone else arrives and hears this, and I tell him: 'This fellow isn’t insane. We are only doing philosophy.”
― Ludwig Wittgenstein
Re: Gettiers in software engineering (2019)
#10I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring.…
This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just a dark forest of hidden horrors.
When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.