Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Logical fallacies in software engineering

artur-martsinkovskyi.github.io

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Logical fallacies in software engineering

#61

Post by shados »

mason55 wrote: post #57
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…

As a counterpoint to that, in some cases technology is changing so rapidly that things which were best practices no longer are and vice versa. Things that we take for granted now, like CI/CD, were not even technically possible 20 years ago. If people weren't constantly challenging best practices as new technology came out then we'd still be pushing our CRs through change acceptance boards. Or think about "the cloud,"…

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:)

Re: Logical fallacies in software engineering

#62

Post by p0nce »

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…

Part of the Stone Age is that the good stuff is already out there in books nobody reads, rather than fancy Medium posts.

Re: Logical fallacies in software engineering

#63

Post by lxwang »

MaxBarraclough wrote: post #38
Udik wrote: post #18

Earlier quoted context omitted.

A fallacy I've noticed often in sw engineering, and might fall under the nirvana fallacy definition, is the assumption that there is one best tool for doing things- the one that supports the largest amount of use cases. An metaphor I like to use is that of the software engineer buying a tank instead of a car: fits more people, drives on all terrain, basically indestructible, and in case an enemy is blocking the road…

Not to mention the regulatory issues.

If everyone just buys tanks, eventually they'll have no choice but to change the regulations.

Re: Logical fallacies in software engineering

#64

Post by Silhouette »

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…

For whatever it might be worth, here is my advice to juniors about being mentored:

It mostly is true that the only stupid question is the one you didn’t ask.

Please don’t ask the exact same question twice. Take notes if you need to. Asking for clarification or following up for more detail is fine.

If you have many questions and your mentor has other responsibilities, try not to keep interrupting them all the time. Discuss the best way to balance your needs and theirs, perhaps finding a time/place/medium where you can have a larger discussion and deal with several questions at once.

Assuming your mentor has accepted that responsibility voluntarily, they’ll probably be happy to help even with the basic stuff — we all had to start somewhere — but will appreciate it not taking over their whole day.

Re: Logical fallacies in software engineering

#65

Post by BeetleB »

argd678 wrote: post #51

> Some engineers may use such fallacy, exposing all the technicalities of their job to cover incompetence and justify failure in rolling out feature in time. 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. D…

>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 effort on making code more readable. As such, there can exist multiple logically sound arguments that give opposing conclusions. Then they start to appeal to authority.

In my experience, people don't appeal to authority for factual things like "your loop could potentially never terminate under conditions X." (fact) They appeal to authority for statements like "In C++, you should never inherit from a class that does not have a virtual destructor." (opinion)

Re: Logical fallacies in software engineering

#66

Post by adrianmonk »

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 an inefficient algorithm, but you isolate that so that later you can create a drop-in replacement that is optimal.

For me, at least, it's mentally freeing to just take a little time to verify I haven't painted myself into a corner. Once I know that, I'm satisfied and can more easily move on to build the imperfect system I need to build now.

Re: Logical fallacies in software engineering

#67

Post by Vinnl »

akvadrako wrote: post #55
Vinnl wrote: post #44

Earlier quoted context omitted.

"Appeal to authority" is a fallacy in the case where someone asserts authority where they have none, e.g. taking a scientist's advice on a subject because they're a scientist, even though their specialisation is completely unrelated to the subject at hand. Deferring to relevant expert opinion is really the only thing you can do for the vast majority of things, since you can only be an expert in so many things. Unfort…

That’s not what it means at all. Of course relying on false authorities is bad. Like all “fallacies” it’s not that they are useless, it’s just that you have to be aware of the traps. Even the best experts in an area often disagree, so you can’t logically deduce that expert says X means X is true.

You're right that the actual fallacy is using an appeal to authority as proof for a statement - that is wrong.

However, it's perfectly fine to defer to an authority as a working hypothesis when you're not proving something, though - unless that authority does not have relevant expertise.

I think my point is probably better worded by https://yourlogicalfallacyis.com/appeal-to-authority

> nor is it reasonable to disregard the claims of experts who have a demonstrated depth of knowledge unless one has a similar level of understanding and/or access to empirical evidence.

But that does not dismiss that you're entirely right in that

> it is entirely possible that the opinion of a person or institution of authority is wrong; therefore the authority that such a person or institution holds does not have any intrinsic bearing upon whether their claims are true or not.

Re: Logical fallacies in software engineering

#68

Post by lazyasciiart »

mgkimsal wrote: post #29
afranchuk wrote: post #16

I'm constantly fighting the sunk cost fallacy with managers, I'm surprised it hasn't been mentioned, or maybe it has been but in a different form?

"Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)" WRT software projects, what's the opposite? When I bring up sunk cost, the assumption is that I'm lobbying for wholesale rewrite. In some (not all) cases I am - take the lessons learned, maybe some algorithms, data, whatever, and rebuild. The standard rejoinder to t…

You clearly lay out the future costs of both options in a way that demonstrates you aren't just unaware of how much work will go into the change.

That said, rewriting a system you don't understand is pretty hard to do successfully.

Re: Logical fallacies in software engineering

#69

Post by BeetleB »

Udik wrote: post #18
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.

A fallacy I've noticed often in sw engineering, and might fall under the nirvana fallacy definition, is the assumption that there is one best tool for doing things- the one that supports the largest amount of use cases. An metaphor I like to use is that of the software engineer buying a tank instead of a car: fits more people, drives on all terrain, basically indestructible, and in case an enemy is blocking the road…

>A fallacy I've noticed often in sw engineering, and might fall under the nirvana fallacy definition, is the assumption that there is one best tool for doing things

AKA "We must use git." :-)

Re: Logical fallacies in software engineering

#70

Post by BeetleB »

zzzcpan wrote: post #17
tide_ad wrote: post #11

> Appeal to Authority .... When explaining practices or opinions on some subjects of sofware development, project management, operations, e.t.c, people tend to use somebody elses saying, blogpost, conference talk or other claim as a foundation for justification of their own decision. I consciously do this these days because other people are gullible. I consciously know "well this isn't balanced", but there is no need…

Define works. Appeal to authority destroys engineering, scientific, critical thinking and decision making. You can't appeal to authority your way into subject experts, they might even openly criticize you for your bullshit.

>Define works. Appeal to authority destroys engineering, scientific, critical thinking and decision making.

Appeal to authority is a tool. Whether it improves or worsens things depends on how it is wielded.

Post reply on HN