4 ms·
> Customers Ah I see what you mean. Problem of language then. "Finding bugs", to me as a coder, means something different from observing the effects of bugs.
by nonrandomstring 2y ago
> Customers
Ah I see what you mean.
Problem of language then.
"Finding bugs", to me as a coder, means something different from
observing the effects of bugs.
Sure, I can see incorrect behaviours in lots of proprietary software.
And I can guess what might cause it. But without the source code
that's not the same as "finding bugs".
- xyzzy_plugh 2y ago"finding a bug" in source code implies there's a mistake there. A bug can be that the implementation doesn't match the spec, or that the spec changed, with respect to the user (customer). Reporting bugs vs finding them is perhaps what you're looking for, but I'd argue finding is overloaded. It's perfectly valid to kick the tires on some software and find some bugs. I've found thousands of bugs in closed source software before, and subsequently reported those bugs.
- nonrandomstring 2y ago> "finding a bug" in source code implies there's a mistake there. This is a good point of course. Implementation, protocol and runtime bugs are indeed invisible from the source POV. As are lower level Ken Thompson "trusting trust" [0,1] bugs in your tool chain. Most of all though, many "bugs" are just malicious functions the coders meant to put in there. [0] https://cybershow.uk/episodes.php?id=2 https://cybershow.uk/episodes.php?id=2 [1] www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf