Live data from Hacker News

Logical fallacies in software engineering

artur-martsinkovskyi.github.io

91–100 of 151 posts

Re: Logical fallacies in software engineering

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

It's just a logical fallacy because it can't be used as a concrete building block to advance a logical argument forward. Doesn't mean it's not useful, it just means that you're no longer logically air tight.

Re: Logical fallacies in software engineering

#93
post #71

Sometimes a helpful antidote to the nirvana fallacy is to choose a solution which doesn't preclude perfection. It's one thing to make a decision which blocks you off from ever solving the problem the really correct way. It's another thing to not achieve perfection now but leave open a path to going back and improving certain parts later so you eventually get there. For example, maybe one component of your code uses a…

1000% agree. My team is in the middle of building a new system, and it’s gotten to the point where I’ve found myself saying the phrase “let’s not paint ourselves in a corner” 2-3 times a day. An additional benefit is that you get to testing your solution in the real world sooner, shaping your perception of perfection (and therefore the list of needed improvements) in production rather than on paper.

... and then one day you finally scale with massive traction... every single potential customer shows up on the same day, and all leave with bad impressions, never to return or consider returning again.

Re: Logical fallacies in software engineering

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

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 authority is the rational thing to do. If you yourself aren't an expert, then you lack the expertise needed to evaluate any arguments purely based on merit. You'd be far better off relying on expert advice, even if the person you're debating with has suggested something different and is more knowledge than you.

It takes a lot of objectivity and humility to know which fields you are and aren't an expert in. Overestimating your skills may feel good, but will only slow your progress and lead to bad decisions. The vast majority of the time, you're better off following expert advice.

Re: Logical fallacies in software engineering

#95
post #94
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…

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 to your detriment. An "Appeal to hypocrisy" can serve to highlight when the person you debate with wants you to stop doing something (because eg. they say its bad) but keeps for themselves the benefits of keeping doing to (and thus gets the upper hand on you). And so on.

Still, like those things "Appeal to authority" is not a logical proof based on the content under discussion (and axioms, logical steps etc), but a "because X says so" on the status of person X (eg. their expertise).

That's what makes it a fallacy. Whether what that person says is true or not, or even whether it's more likely true than not, is irrelevant.

In either case, it's not a logical proof (in the formal sense) nor a definite proof (the person with the expertise could for example be lying to further their interests, or mislead for some other reason).

Re: Logical fallacies in software engineering

#96
post #90
post #65

Earlier quoted context omitted.

>This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend e…

Good example, was that from Effective C++? Widely repeated, yet wrong.

I am not following. Sure you can, sure it may work now, but it seems like something that is a recipe for future bugs being created?

Re: Logical fallacies in software engineering

#97
Chesterton’s fence is one I come across a lot. People see some confusing or not ideal code and immediately want to remove it, without understanding its purpose. I like stating it as “don’t assume the previous developers were idiots.”

https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...

Re: Logical fallacies in software engineering

#98
post #61

Earlier quoted context omitted.

Good point, absolutely! The line is really thin between industry changing stuff (CI, cloud, distributed version control, type systems that don't suck, etc) and reinventing the wheel through arrogance or just not knowing any better (yet another testing framework, screwing up some well studied patterns :cough Java Optionals cough:)

The graybeards among us might chuckle at the thought of calling it "distributed version control" when the CI system requires a centralized copy of the repository acting as a source of truth in order to work.

CI systems only need the "centralized" copy as a reference point of what the current master is. Everyone gets their own entire copy of that repository though. If the truth suddenly changes it's known. I also know that if the copy in the "centralized" matches my own then the CI is also running exactly my code. If the centralized machine fails I can fail it over to any copy on any machine. That seems pretty distributed to me as compared to the original "distributed" version: e-mailing source code around. Version control like SVN and CVS were centralized in that me having a copy of the source and you having a copy of the source indicated nothing about whose version is correct. Moreover a failure of the central spot in the system is fatal unless you had backups as a form of pseudo-distribution whereas in today's version control a failure on any one machine is irrelevant to the preservation of the system.

Re: Logical fallacies in software engineering

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

it depends greatly how Kasparov tells you what to do. if it's "do this because I'm kasparov", or "do this, because your next move could be this and it gives you this opportunity". same with software. someone telling to do this because I'm senior engineer is appeal to authority.

Re: Logical fallacies in software engineering

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

No. Absolutely not. If the person is actually an incredible authority they will have no trouble making a compelling argument or providing strong evidence.

This is never confusing unless you lack objectivity.

Post reply on HN