The real world is far too complex to reject an idea outright simply because the way it's presented checks a logical fallacy box. Unless the person presenting it to you has some ulterior motive please consider that they are taking the time to explain something to you because they genuinely believe you might benefit from it.
Logical fallacies in software engineering
131–140 of 151 posts
Re: Logical fallacies in software engineering
#132Not specific to software engineering, but there's a very interesting book about logical fallacies and the tricks that our brain play on us, Thinking: Fast and Slow, by nobel prize winner Daniel Kahneman
Re: Logical fallacies in software engineering
#133Earlier quoted context omitted.
> But if either party in the debate isn't an expert, then appealing to authority is the rational thing to do. It might be the "rational thing to do" but it's not a logical argument -- which is what makes it a fallacy. Fallacies can often be the logical thing to do. E.g. an "Ad Hominem Fallacy" might save your ass when the other person puts forward a perfectly logical argument, but to serve their own selfish reasons t…
We're arguing over semantics here. Most people interpret a "fallacy" as something one should refrain from. Ie, "appeal-to-authority is a fallacy, therefore we should refrain from it during the course of any discussion". I'm making the point that often times, appealing to authority is most likely to produce the correct answer.
>I'm making the point that often times, appealing to authority is most likely to produce the correct answer.
That's true for most so-called fallacies. Instead they are evolutionary shortcuts to getting the correct answer (at least at evolutionary kind of situations).
Re: Logical fallacies in software engineering
#134Earlier quoted context omitted.
I come across the reverse version, too. I mean, the fallacy of labels - situations just like your example, but where (say) Agile methodology was INDEED not properly followed, despite being branded as such.
Agile is a set of values, not a methodology. You're thinking of scrum or extreme programming or kanban or something more specific.
I really hope this was an attempt at deadpan humor given the grandparent of this comment.
Re: Logical fallacies in software engineering
#135Earlier quoted context omitted.
When somebody presents me with a new shiny solution to a hard problem describing it as a silver bullet, I immediately become suspicious. So, it depends a lot on how good Pat says that Y is.
Do these people actually say, “this is a silver bullet” or is that your interpretation? Does this mean is pat undersells you on Y you might be more receptive?
It's not about underselling, it's about showing awareness that there are always tradeoffs. I'm much more receptive when they did their due diligence about those and the risks for the project.
Re: Logical fallacies in software engineering
#136I'm late to the conversation, but one thing I see causing a lot of unnecessary complexity is applying the same ideas and concepts at different levels of abstraction because it "intuitively" feels right. I'd like to call this "appeal to symmetry" or "appeal to completionism". Example:
* You have a CI/CD pipeline deploying an application artefact though test->staging->prod.
* You update your pipeline to treat the deployment script itself as an artefact that gets promoted as well, because hey — shouldn't our test code also be tested? And it's just a couple of configuration changes.
* You say "well everything else is an artefact so how come our pipelines aren't?" and start implementing CI/CD for your CI/CD for your CI/CD.
Re: Logical fallacies in software engineering
#137A millenium lasts for 1000 years. Early versions of brains came about around 600 million years ago.
Re: Logical fallacies in software engineering
#138Earlier quoted context omitted.
We're arguing over semantics here. Most people interpret a "fallacy" as something one should refrain from. Ie, "appeal-to-authority is a fallacy, therefore we should refrain from it during the course of any discussion". I'm making the point that often times, appealing to authority is most likely to produce the correct answer.
> I'm making the point that often times, appealing to authority is most likely to produce the correct answer. That's true for most so-called fallacies. Instead they are evolutionary shortcuts to getting the correct answer (at least at evolutionary kind of situations).
How does committing the strawman fallacy help in producing the correct answer?
Re: Logical fallacies in software engineering
#139The concept of "fallacies" is somewhat overdone, to the point where I'm tempted to coin the "fallacy fallacy". They are used far too often to shut down some debate: Oh, you want to do this yourself? Not-Invented-Here-Syndrom! Oh, you want to buy from a reputable vendor? Appealing to authority! I believe the "appeal to authority" fallacy is especially misguided: it's impossible to verify every statement we rely on fro…
Appeal to authority is a fallacy exactly because you can't trust New York Times just as you can't trust @TheyAreTryingToKillYou241234, but you do. An authoritative opinion is not an evidence.
Setting impossible standards only keeps you believing what you want to believe and what you already believe. It's logically equivalent to blind faith, you believe what you want to believe rather than what has most (even if imperfect) evidence.
You are forgetting that your status quo belief also has to come from somewhere, and its quality of evidence is probably worse than those alternatives you are attacking for not being good enough to change your belief. If it was better you would present it.
Re: Logical fallacies in software engineering
#140Earlier quoted context omitted.
Good example, was that from Effective C++? Widely repeated, yet wrong.
>Widely repeated, yet wrong. Not right, either. Personally, I wouldn't inherit from a class that didn't have a virtual destructor unless I had a good reason. The point isn't whether it is right or wrong. Stating it as wrong is as problematic as stating it as right. The point is that whether it is OK to do it or not is an opinion , not a fact, and should be discussed as such.
you are right, I was trying to say the "never" part is wrong but of course there is a good reason behind the advice; it's not pure bullshit.