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

41–50 of 151 posts

Re: Logical fallacies in software engineering

#41

Post by robluxus »

diNgUrAndI wrote: post #28

> Misleading vividness – involves describing an occurrence in vivid detail, even if it is an exceptional occurrence, to convince someone that it is a problem; this also relies on the appeal to emotion fallacy. 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. I think experienced co-workers can tell whether you ar…

I think too much experience can also cause this. I see this from time to time when we design new systems or products: everyone is optimistic about the idea but the more senior people you have in the room there's more chance someone paints vivid pictures of how everything could fall horribly into pieces if we meet this one corner case that they saw in a slightly related project 2 decades and 5 companies ago.

Re: Logical fallacies in software engineering

#43

Post by astrobe_ »

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…

But a tank is so much more powerful.

Re: Logical fallacies in software engineering

#44

Post by Vinnl »

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…

"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. Unfortunately, "appeal to authority" is sometimes interpreted in a way so as to discredit authority in general.

Re: Logical fallacies in software engineering

#45

Post by wpasc »

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…

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 they feel comfortable not knowing things. Moreover, plenty of senior engineers do not make good mentors (either don't want to or don't have the strongest of communication and mentoring skills).

You'll have a crop of engineers with 0-2 years experience that don't feel comfortable not knowing something because they feel it can be a sign of technical weakness. Perfectly valid questions go unasked and a young engineer may spend 3-4 days trying to answer something that his mentor could help him/her with in 15 minutes.

Great knowledge isn't transferred optimally in this scenario.

Re: Logical fallacies in software engineering

#46

Post by jmull »

wolfgke wrote: post #21
marcosdumay wrote: post #8

Earlier quoted context omitted.

Isn't this correct in English? The equivalent on my first language (Portuguese) is very clearly wrong, but I've seen the English version in more than one book.

> Isn't this correct in English? I, as a non-native English speaker, would write "thrice at perception, dexterity and mind work" (instead of "both at perception, dexterity and mind work"), but I am not sure whether this is overly formal (it is, in my experience, often the case that when you try to translate how you would express something in German into English, you land at something overly formal, since in German th…

Thrice doesn’t really fit the sentiment of the sentence there. It would be best to replace “both” with nothing in that sentence when moving from two to three items.

“Both” itself isn’t necessary when dealing with two items (not that it hurts, IMO). It could serve a rhetorical purpose if you particularly wanted to emphasize the equal relationship between the two items. E.g., if one item might normally be perceived as significantly more important than the other, “both” is a way to address the surprise or skepticism the reader may feel seeing them placed together equally.

Re: Logical fallacies in software engineering

#47

Post by zachrose »

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:

This touches on another thing, which is “Thing X is known to be imperfect, Pat says thing Y is better. Nobody else on the team has tried Y but we have all these aphorisms like ‘no silver bullet’ that lead us to think Y can’t be that good.”

Re: Logical fallacies in software engineering

#48

Post by icxa »

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…

Mentorship at the highest level (principle to senior and below) is desperately lacking. I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting.

I pair programmed for 3 months (which I consider apprenticeship / live action mentorship) with someone who was a way better engineer than me at my first "career job" out of college. I learned more in those 3 months about software engineering than in my previous two.

Re: Logical fallacies in software engineering

#49

Post by cuspycode »

marcosdumay wrote: post #8
johnr2 wrote: post #5

"both at perception, dexterity and mind work" Off-by-one error ;-)

Isn't this correct in English? The equivalent on my first language (Portuguese) is very clearly wrong, but I've seen the English version in more than one book.

I interpret this as using the binary operation "both" in a reduction over a list of three items. Kind of like how you can add a list of numbers through e.g. (PLUS 1 2 3 4) in LISP, although addition is actually a binary operation.

Re: Logical fallacies in software engineering

#50

Post by mindondrugs »

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…

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 stressful week.
Post reply on HN