Logical fallacies in software engineering • Hacker News Board

Re: Logical fallacies in software engineering

#111

Post by sidlls » Sun, May 26, 2019, 8:32 PM UTC

coldtea wrote: post #95

whack wrote: post #94

Earlier quoted context omitted.

I think this fallacy is the most widely misunderstood fallacy of all. In an argument between experts , appeal-to-authority is indeed a fallacy. If both people are indeed experts, they should be able to judge something purely on its merits. This is similar to the scientific method where debates are settled by logic and evidence, not seniority. But if either party in the debate isn't an expert, then appealing to author…

> 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…

The word "fallacy" as used in the OP seems to me to be a shorthand for "belief or opinion not backed by solid observational evidence and/or reasoning". It doesn't seem to apply to the case of constructing an argument in the logical or philosophical sense.

Re: Logical fallacies in software engineering

#112

Post by zzo38computer » Sun, May 26, 2019, 8:39 PM UTC

Shish2k wrote: post #26

stupidcar wrote: post #7

The "nirvana fallacy" is definitely one I commonly see on Hacker News. The ease with which people jump from "thing x is imperfect" to "thing x is worthless" is mind-boggling. This is usually coupled with familiarity bias, where the flaws of any existing technology are discounted vs. those of a new technology.

Also frequently combined as "Thing X is known to be imperfect, so thing Y which we've never tried before must be better" D:

Y is not necessarily better than X, but perhaps you should look to see in case perhaps Y is actually better. (Or maybe in some ways it is better and other ways not so much better. Or maybe it is better for what they are doing but not you.)

Also, sometimes something is, although not perfect, can be improved without breaking or making it too messy, but, sometimes not.

Re: Logical fallacies in software engineering

#113

Post by AmericanChopper » Sun, May 26, 2019, 8:56 PM UTC

chadash wrote: post #34

> Appeal to authority (argument from authority, argumentum ad verecundiam) – an assertion is deemed true because of the position or authority of the person asserting it. You have to be careful with this one. When someone has enough credibility, sometimes you need to question yourself if you disagree. If you are playing chess and Gary Kasparov comes along and tells you what your next move should be, you can disagree w…

>If you are playing chess and Gary Kasparov comes along and tells you what your next move should be, you can disagree with him, and you might even be right, but given his expertise in chess, his move is most likely going to be better than yours and it's worth considering

If you already had a plan to win the game, but have no idea how to continue Kasparov’s line, then it doesn’t matter how strong his move is, you’re just going to be shooting yourself in the foot by making it.

In technology though, things are different. You can precisely quantify the strength of a chess move, you usually can’t even imprecisely quantify the strength of most advice about technology. In my experience, experts tend to be no better or worse at separating their own personal opinions from more objective truths.

In any case, the appeal to authority shouldn’t be necessary. If an expert is right about something, they should be able to explain to a non-expert why they’re right.

Re: Logical fallacies in software engineering

#114

Post by [deleted] » Sun, May 26, 2019, 8:58 PM UTC

mindondrugs wrote: post #50

wpasc wrote: post #45

Earlier quoted context omitted.

May I add to this with a third: difficulty in creating a strong system of mentoring? Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies). In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that…

Oh man, I relate to this feeling tremendously. I am a junior dev on an apprentice program (just shy of 1 years experience to date) and the times I have struggled with something because I let my pride, or fear of bothering people with inane questions, have been the lowest points in the last year. I always get to the otherside wishing I just talked to a senior dev - because more likely they could have saved me a stress…

[deleted]

Re: Logical fallacies in software engineering

#115

Post by WalterBright » Sun, May 26, 2019, 9:01 PM UTC

shados wrote: post #37

chadash wrote: post #34

> Appeal to authority (argument from authority, argumentum ad verecundiam) – an assertion is deemed true because of the position or authority of the person asserting it. You have to be careful with this one. When someone has enough credibility, sometimes you need to question yourself if you disagree. If you are playing chess and Gary Kasparov comes along and tells you what your next move should be, you can disagree w…

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason. The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter…

I'd add to that the predilection for hiring young engineers and overlooking older ones. While it's true that older ones can get stuck in past practices, they also recognize things that have been tried before, seem like good ideas, but just don't work for non-obvious reasons.

For example, implicit declaration of variables in programming languages.

A strong team will have a mix of older and younger engineers.

Re: Logical fallacies in software engineering

#116

Post by dnautics » Sun, May 26, 2019, 9:02 PM UTC

chadash wrote: post #34

> Appeal to authority (argument from authority, argumentum ad verecundiam) – an assertion is deemed true because of the position or authority of the person asserting it. You have to be careful with this one. When someone has enough credibility, sometimes you need to question yourself if you disagree. If you are playing chess and Gary Kasparov comes along and tells you what your next move should be, you can disagree w…

You also have to be careful about who the authority is and how they got to be an authority. Gary Kasparov obviously got to his place via a metric which is hard to argue against; you don't know how a senior dev got promoted to be a senior dev. I know a senior "engineer" but really a dev who's rewritten this one piece of software, first in go, then in c++, then in go, over the course of a year. There are no unit tests and no integration tests. Documentation is spotty. A second senior who has a PhD in engineering and no go experience started work and she immediately found several race conditions and complained that the code was written in a fashion that was provably incompatible with concurrency.

Re: Logical fallacies in software engineering

#117

Post by WalterBright » Sun, May 26, 2019, 9:03 PM UTC

wpasc wrote: post #45

shados wrote: post #37

Earlier quoted context omitted.

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason. The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter…

May I add to this with a third: difficulty in creating a strong system of mentoring? Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies). In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that…

It's much worse than 3-4 days of wasted effort. A bad design can get so baked in it's nearly impossible to correct.

Re: Logical fallacies in software engineering

#118

Post by [deleted] » Sun, May 26, 2019, 9:06 PM UTC

WalterBright wrote: post #117

wpasc wrote: post #45

Earlier quoted context omitted.

May I add to this with a third: difficulty in creating a strong system of mentoring? Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies). In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that…

It's much worse than 3-4 days of wasted effort. A bad design can get so baked in it's nearly impossible to correct.

[deleted]

Re: Logical fallacies in software engineering

#119

Post by MaulingMonkey » Sun, May 26, 2019, 9:24 PM UTC

Noumenon72 wrote: post #74

austincheney wrote: post #9

Many logical fallacies I encounter as a developer are actively exercised so that a developer can save face or justify their existence through appeals to the ignorance of business leaders. Some I have noticed as a JavaScript developer: * Appeal to Popularity, a modification of appeal to authority. Essentially this says if a tool or approach is popular it is correct. The common assertion is that popular approaches must…

Student fallacy is also called Baby Duck fallacy, because you imprint on the first thing you see. To this day I have no idea whether Git actually sucks or I just saw Mercurial first.

Git actually sucks - but it's got the right kind of brain damage to really appeal to me. E.g. most VCSes - including SVN, which I started with - treat branches as just folders. This is a clean, elegant abstraction, with low mental overhead. But I still prefer the mess that is git's branches/tags/annotated tags/stashes, it works much better with my ex post facto treatment of branches, and doesn't require me to constantly reopen things as I swap around between branches. (EDIT: This is in fact the main reason I standardized on git when I decided SVN wasn't cutting it anymore!)

The command line interface is an incoherent mess by any objective standard, and I still have to routinely read docs for it. The GUIs are even worse, and scale even worse than the vanilla git command line. Partial workarounds for it's poor scaling like git lfs or git annex are awkward to use, made worse by github's LFS quotas/caps.

Re: Logical fallacies in software engineering

#120

Post by whack » Sun, May 26, 2019, 9:53 PM UTC

coldtea wrote: post #95

whack wrote: post #94

Earlier quoted context omitted.

I think this fallacy is the most widely misunderstood fallacy of all. In an argument between experts , appeal-to-authority is indeed a fallacy. If both people are indeed experts, they should be able to judge something purely on its merits. This is similar to the scientific method where debates are settled by logic and evidence, not seniority. But if either party in the debate isn't an expert, then appealing to author…

> 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.