3 ms·
> You seem to say your definition of "good enough" is based on good, risk-based judgement. Not at all. I said that "good enough" is a contextual, subjective ju
by shkkmo 5y ago
> You seem to say your definition of "good enough" is based on good, risk-based judgement.
Not at all. I said that "good enough" is a contextual, subjective judgement and is a critical part of software engineering. The idiom "good enough" says nothing about quality of that subjective judgment, despite your insistence that it does.
> I'm saying people's cognitive biases can lead to them discounting risk without good evidence because it results in a decision they are emotionally attached to
Of course cognitive biases (and all sorts of other things) can degrade judgment. That doesn't mean that we should try to get by without it. We seem to be in agreement on this.
> that is not the context that the term "good enough" is generally used in practice.
Here you are simply wrong. "Good enough" means " adequate but not perfect, not "sub-standard". While it is possible you have been operating in a cultural bubble where that term is only used to mean "sub-standard", in this context the meaning of "good enough" that is being used has been clarified repeatedly but you insist that only your experience with the term matters and thus everyone must use your definition. Instead of working to understand what people are saying, you assume that they are using your definition. Perhaps this sort of assumption explains why you somehow missed out on noticing everyone who uses that term in the normal way. Seriously, go look as some definitions and try asking people what they mean when they use the term.
> That point of digression between what I'm saying and what you're interpreting seemed to fly right by you
Another example of you not really listening. I've repeatedly pointed out this exact divergence.
- bumby 5y agoNote that you specific left out the contextual clue where I said "In my experience" that is not how it's used in practice as an immediate follow-up to that sentence about how it's used. I am not making a general case, but talking specifically about safety-critical code from the very start. I am not saying everyone must use my definition in the general case. I'm saying in the very specific subset of cases, there is an objective definition for good reason. Let me try a different tack to see if we can get off this pedantic merry-go-round. You've agreed that cognitive biases affect decision-making. So let's say as a developer you are working on safety-critical code that is in danger of being over schedule and over budget. Their manager says if the project isn't successful, your company will lose future work to a competitor and that might leave you out of a job. But if it is delivered on time, you're company will get a massive windfall in terms of future contracts and profits, and likely lead you to a big promotion. What do you do to ensure those cognitive biases do not influence you to incorrectly discount risks and ship the software early before the risks are properly addressed? (Btw, it's a really bad method of communicating to use absolute terms like 'everyone'. For one, it makes it look like you think you're smarter than you are and more importantly, it's easily falsifiable. That type of communication belongs more on r/iamverysmart than HN)