26 ms·

Logical fallacies in software engineering

242 points by gentleterror 7y ago

johnr2 7y ago
"both at perception, dexterity and mind work" Off-by-one error ;-)
- marcosdumay 7y ago
  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.
  - rzzzt 7y ago
    "Equally" would be a better instead of "both" if they are, indeed, weighed equally, or just skip "both" altogether and maybe add an "as well as" before the last item on the list: https://english.stackexchange.com/questions/22357/equivalent-of-both-when-referring-to-three-or-more-items https://english.stackexchange.com/questions/22357/equivalent...
  - wolfgke 7y ago
    > 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 the commonly used language register is more formal than in English).
    - wincy 7y ago
      An American native speaker would certainly understand and not raise an eyebrow at using “both” in this context, even though technically it means two not three. Using “thrice” is sort of archaic and formal (like you mentioned) and people would maybe make a good natured joke about being “fancy” if you used the word “thrice” often in conversation. Oddly though twice has none of the baggage of thrice, and is used all the time. My four year old knows and uses twice, but doesn’t know what thrice means.
    - jmull 7y ago
      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.
  - 0xffff2 7y ago
    It's definitely not technically correct. "Both" in English unambiguously refers to two things.
    - adrianmonk 7y ago
      One dictionary says "two or more" and even cites a Samuel Taylor Coleridge example with three things: From https://www.merriam-webster.com/dictionary/both https://www.merriam-webster.com/dictionary/both : > both conjunction —used as a function word to indicate and stress the inclusion of each of two or more things specified by coordinated words, phrases, or clauses prized both for its beauty and for its utility he … who loveth well both man and bird and beast — S. T. Coleridge
  - ummonk 7y ago
    "Both" refers to two. If you're referring to the the lack of a serial comma, it isn't "incorrect" in American English but should be, and most style guides recommend using the serial comma.
  - cuspycode 7y ago
    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.
  - adrianratnapala 7y ago
    It's definitely wrong. But it is blasphemous to even believe that there can be right or wrong in such matters.
hestefisk 7y ago
404?
- progval 7y ago
  https://artur-martsinkovskyi.github.io//2018/logical-fallacies-in-programming/ https://artur-martsinkovskyi.github.io//2018/logical-fallaci...
Folcon 7y ago
Incorrect url, should be: https://artur-martsinkovskyi.github.io/2018/logical-fallacies-in-programming/ https://artur-martsinkovskyi.github.io/2018/logical-fallacie...
wazanator 7y ago
Needs my favorite, "age = wisdom & knowledge". "Bob's been here for fifteen years and if he says java applets are still the way to go then they must be."
- tirumaraiselvan 7y ago
  Appeal to authority - mentioned in the article.
  - MaxBarraclough 7y ago
    It's not strictly identical, as it introduces ageism.
    - tirumaraiselvan 7y ago
      True. But age is used as a good proxy for determining authority.
stupidcar 7y ago
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.
- Udik 7y ago
  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 you can always shoot it from the turret. Of course, it's horrendously expensive, wildly impractical, and you have to demolish your garage and rebuild it to fit it in, but hey, that was the best choice.
  - austincheney 7y ago
    Speaking of tanks and fallacies... https://www.amazon.com/Pentagon-Wars-Reformers-Challenge-Guard/dp/1557500819/ref=sr_1_1?keywords=pentagon+wars+burton&qid=1558882108&s=gateway&sr=8-1 https://www.amazon.com/Pentagon-Wars-Reformers-Challenge-Gua...
  - MaxBarraclough 7y ago
    Not to mention the regulatory issues.
    - lxwang 7y ago
      If everyone just buys tanks, eventually they'll have no choice but to change the regulations.
  - astrobe_ 7y ago
    But a tank is so much more powerful.
austincheney 7y ago
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 be correct as many eyes would have found and reported any problems. This fallacy also explains why horrendous highly visible bugs can present in exceedingly popular applications for long periods of time, because developers simply believe the strength and wisdom of the community are enough to identify, report, and resolve any issue in a timely manner. Software isn't magic and isn't magically updated or repaired because its popular. * Invented Here. This is the opposite of the more well known Not Invented Here, which asserts that developers are irrationally afraid to write original code. The common assertion is that any original code whether from you or your coworkers is a horrid mistake, because somebody else has done it better. The common defense is that developers are standing on the shoulders of giants. * Toolsmith Fallacy. This is an extension of the above mentioned invented here fallacy in that use of tools is good and the use of more tools is likely better. This line of thinking is how we end up with stupidity like left-pad and how a simple 30 line tool could have hundreds of dependencies whose total weight exceeds hundreds of megabytes. This fallacy is also dangerous when it asserts that dependencies don't need to be tested since the assumption is that they are better than original code. * Student Fallacy. This asserts that the approach first learned is most correct. This fallacy is used as a bias against differing ways to solve a problem so that a developer can maintain confidence and save face when criticized or encounters something they don't understand. * Big Fallacy. This asserts that when something becomes large or poorly understood it should be dismissed out of hand. This is essentially a bias against reading code, which is the required first step before refactoring any given approach into something more comprehensible. This fallacy completely ignores that fact that a given artifact may do the job perfectly well with great performance. * Framework Fallacy. This fallacy is an extension of the toolsmith fallacy and basically says a given approach cannot be achieved without a given tool if there is a tool that claims to address the problem. * Assembly Fallacy. I have not seen this one in a while, but when jQuery was really popular any attempt to write code without use of jQuery was immediately compared to writing assembly. * DOM is slow. Most people making this claim don't really seem to know what the DOM is. Here is the DOM that modern web browsers use: https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/ This one is highly technical and makes many people sad, so I won't go into this here. * Open Source is a My Personal Gift. This fallacy asserts that free software is a gift provided for you. Open source software, like any software, takes effort of a person writing software. If you want a new feature submit a pull request. It is astonishing to see the hostility that arises when this is mentioned.
tide_ad 7y ago
> 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 to put a disclaimer on that, it just wastes your time and confuses the recipient. Appeal to Authority works.
- zzzcpan 7y ago
  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.
  - tide_ad 7y ago
    > You can't appeal to authority your way into subject experts, they might even openly criticize you for your bullshit. They might, and they might also ignore you without a source because they are so focused on discrediting everyone thats not themselves. > Define works. Gets people to more quickly agree with your line of reasoning, by masquerading your line of reasoning as a non-independent thought and simply finding something that agrees with you on Google. I know that search engines mostly just agree with you. Other people don't.
  - BeetleB 7y ago
    >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.
shaki-dora 7y ago
The 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 from first principle. At some point, when the New York Times has an article highlighting the benefits of vaccinations, while @TheyAreTryingToKillYou241234 on twitter says the MMR vaccine will cause your kids to grow a second head, it is perfectly fine, or even necessary, to consider the source of some information as evidence in evaluating it. This mechanism, of evaluating sources of time and establishing trust, is so pervasive we tend not to even notice it. You are far more likely to hand your car keys to your spouse when asked than to a random stranger.
- Udik 7y ago
  Fallacy fallacy exists: assuming that because a reasoning contains a fallacy, its conclusions must be wrong. They're simply unproven. https://en.m.wikipedia.org/wiki/Argument_from_fallacy https://en.m.wikipedia.org/wiki/Argument_from_fallacy https://existentialcomics.com/comic/9 https://existentialcomics.com/comic/9
- zzzcpan 7y ago
  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.
  - matt4077 7y ago
    So how are you supposed to make an informed choice on vaccination? You can't trust the NYT, apparently, and probably not the New England Journal of Medicine, either? Do you just count the number of sources supporting the different views? That would seem to be some other, equally bad, form of fallacy. Is there any sort of evidence that is valid in your critical eyes that can be transmitted electronically? Or does anyone faced with the choice to vaccinate their children have to run their own randomised clinical trial? That would seem prohibitively cumbersome, and also logically inconsistent because you would have to find a few thousand people willing to participate in your trial who shouldn't trust you not to poison them, by your logic.
Udik 7y ago
No true Scotsman's: - We followed agile methodology and failed miserably. - Then you weren't using real agile.
- V-2 7y ago
  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.
  - humanrebar 7y ago
    Agile is a set of values, not a methodology. You're thinking of scrum or extreme programming or kanban or something more specific.
    - jacquesm 7y ago
      I really hope this was an attempt at deadpan humor given the grandparent of this comment.
      - humanrebar 7y ago
        Nope. The Agile Manifesto is a list of values. There's no method to misapply. The real irony is people claiming to "value individuals and interactions over processes and tools" turning around and telling engineers that the problem is their processes and tools.
afranchuk 7y ago
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?
- mgkimsal 7y ago
  "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 that is "what makes you think you're so much smarter/better than the previous team?" Well... sometimes I maybe am. Or... the strength of the current team is just... more demonstrable? Or... there's no one left from the previous team that even understands the previous system, so ever day spent is often wasted in just trying to learn what they did, only to find out... hey - they really just had no clue what they were doing. We've all seen this (and, early on, I likely was in the position of the offending party a few times). But sunk cost fallacy is a real thing. How do you combat it?
  - akvadrako 7y ago
    Wholesale rewrites often have huge future costs, so I don’t think dismissing them is a sunk cost fallacy.
    - mgkimsal 7y ago
      That's not what I was suggesting. I was suggesting that dismissing any calls for any change (whether it's whole rebuild or any degree of aggressive change) is often justified with "but we've already paid $x for this project". Couple that with then also complaining about further costs just grinds my gears. Probably 1/3rd of the projects I've worked on over the last 20 years were software systems that were objectively/measurable poor, and probably half of those warranted a rebuild, and genuinely not 'flavor of the month' justifications. You can't cheaply and safely, for example, run a business on foxpro/db2, relying on one person in a different country with all the source code, running in a virtualized windows XP environment on Windows server 2000, while also wanting to modify your business processes and grow your business. I'm not saying it can't be done, but the costs and risks outweight whatever benefit you've already bought and paid for the last 20 years.
humanrebar 7y ago
> ...solutions to problems are rejected because they are not perfect... I have seen the flip side as well... dismissing an idea as an instance of "too academic" or "perfectionist" problem solving. It's actually pretty hard to take the time to understand someone's thoughts well enough to differentiate between a complex but real flaw and an aesthetic preference.
diNgUrAndI 7y ago
> 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 are exaggerating or telling the truth. I found someone has the tendencies to elaborate on stuffs in an emotional way. This is especially common in junior devs. From my experience, most senior devs tend to be more reserved and careful about their words. What do you guys think?
- robluxus 7y ago
  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.
chadash 7y ago
> 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 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 (unless, of course, you are chess master at his level). The same thing is true with software. Some people are really strong engineers with really strong expertise in a specific domain. If you follow their advice within their domain of expertise, you might not come to the optimal solution, but you'll probably come to a good enough solution. Of course, there are exceptions, but in my personal experience, I've seen more people mess up by not following experts' advice than by following it.
- shados 7y ago
  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, best practices aren't a thing, etc. The second (and part of the reason the first is a thing), is the amount of people acting as experts that really aren't. Even big names and pseudo-celebrities in the field frequently have no idea what they're talking about. Once people realize this, they start questioning everything. And thus, we're stuck in software engineering stone age. Being unable to separate the good stuff from the bullshit is holding us back a lot.
  - wpasc 7y ago
    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.
diehunde 7y ago
The problem is that most fallacies have a base on cognitive biases. And even when we are aware of them, they are unconscious. So we can't avoid them. But we can try to mitigate them[1]. [1]https://en.wikipedia.org/wiki/Cognitive_bias_mitigation https://en.wikipedia.org/wiki/Cognitive_bias_mitigation
darekkay 7y ago
If you're interested in logical fallacies in general, have a look at my "Logical fallacy of the day" (via RSS, HTML or JSON): https://tips.darekkay.com/html/logical-fallacies-en.html https://tips.darekkay.com/html/logical-fallacies-en.html
argd678 7y ago
> 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. Despite the stereotype of engineers being logical, it’s more they’d like you to see them that way, but are really maybe just 2% more logical in their reasoning than anyone else.
- BeetleB 7y ago
  >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)
  - nullc 7y ago
    > 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. Winner winner, chicken dinner. Some of these things COULD one day be facts, but essentially no one has done the research to determine the fact form of the opinion. "In code of type X maintained like Y, structure Z has been identified to cause a higher defect rate and increased lifetime maintenance costs compared to ZZ" could be a true fact, but seldom do we have any results from rigorous study. Consistency certainly appears very useful, so appealing to some authorities opinion just to get a consistent outcome is probably a reasonable thing to do in many cases. Unfortunately, many people argue for these opinions by first confusing them for facts and defending them as such. We'd often be better off-- in matters of code style or similar-- if teams were more ready to use and accept arguments of the form "that as far as anyone knows option X is at least as good, objectively speaking, as anything other option and for consistency sake we might as well adopt it since {our industry, our team's most prolific reviewer, our existing codebase, etc.} prefers it".
adrianmonk 7y ago
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.
- teucris 7y ago
  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.
  - pg_is_a_butt 7y ago
    ... 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.
nullc 7y ago
https://en.wikipedia.org/wiki/Argument_from_fallacy https://en.wikipedia.org/wiki/Argument_from_fallacy Increasingly, I've seen being blindly dismissive due to awareness of usually helpful but sometimes harmful cognitive heuristics to be a source of mistakes in reasoning. Human reasoning has a multitude of biases and approximations that evolution has preserved in our behavior. They are not always in our best interest, but nor is our alternative behavior when we try to act to contradict them.
jayd16 7y ago
The Historian's fallacy cuts both way. Often the legacy code is convoluted because there's a subtlety that isn't immediately obvious.
nadocrew 7y ago
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_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
l0b0 7y ago
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.
enzoaguado 7y ago
Not 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
ukoki 7y ago
I'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.
mxschumacher 7y ago
A millenium lasts for 1000 years. Early versions of brains came about around 600 million years ago.
heraclius 7y ago
I’m not sure how useful fallacy theory is when applied thus. We’re all quite happy to accept induction (well, software engineers probably should be), and so the use of formally incorrect heuristics is not necessarily a bad idea.

242 points by gentleterror 7y ago

johnr2 7y ago

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

marcosdumay 7y ago
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.
- rzzzt 7y ago
  "Equally" would be a better instead of "both" if they are, indeed, weighed equally, or just skip "both" altogether and maybe add an "as well as" before the last item on the list: https://english.stackexchange.com/questions/22357/equivalent-of-both-when-referring-to-three-or-more-items https://english.stackexchange.com/questions/22357/equivalent...
- wolfgke 7y ago
  > 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 the commonly used language register is more formal than in English).
  - wincy 7y ago
    An American native speaker would certainly understand and not raise an eyebrow at using “both” in this context, even though technically it means two not three. Using “thrice” is sort of archaic and formal (like you mentioned) and people would maybe make a good natured joke about being “fancy” if you used the word “thrice” often in conversation. Oddly though twice has none of the baggage of thrice, and is used all the time. My four year old knows and uses twice, but doesn’t know what thrice means.
  - jmull 7y ago
    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.
- 0xffff2 7y ago
  It's definitely not technically correct. "Both" in English unambiguously refers to two things.
  - adrianmonk 7y ago
    One dictionary says "two or more" and even cites a Samuel Taylor Coleridge example with three things: From https://www.merriam-webster.com/dictionary/both https://www.merriam-webster.com/dictionary/both : > both conjunction —used as a function word to indicate and stress the inclusion of each of two or more things specified by coordinated words, phrases, or clauses prized both for its beauty and for its utility he … who loveth well both man and bird and beast — S. T. Coleridge
- ummonk 7y ago
  "Both" refers to two. If you're referring to the the lack of a serial comma, it isn't "incorrect" in American English but should be, and most style guides recommend using the serial comma.
- cuspycode 7y ago
  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.
- adrianratnapala 7y ago
  It's definitely wrong. But it is blasphemous to even believe that there can be right or wrong in such matters.

hestefisk 7y ago

404?

progval 7y ago
https://artur-martsinkovskyi.github.io//2018/logical-fallacies-in-programming/ https://artur-martsinkovskyi.github.io//2018/logical-fallaci...

Folcon 7y ago

Incorrect url, should be: https://artur-martsinkovskyi.github.io/2018/logical-fallacies-in-programming/ https://artur-martsinkovskyi.github.io/2018/logical-fallacie...

wazanator 7y ago

Needs my favorite, "age = wisdom & knowledge". "Bob's been here for fifteen years and if he says java applets are still the way to go then they must be."

tirumaraiselvan 7y ago
Appeal to authority - mentioned in the article.
- MaxBarraclough 7y ago
  It's not strictly identical, as it introduces ageism.
  - tirumaraiselvan 7y ago
    True. But age is used as a good proxy for determining authority.

stupidcar 7y ago

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.

Udik 7y ago
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 you can always shoot it from the turret. Of course, it's horrendously expensive, wildly impractical, and you have to demolish your garage and rebuild it to fit it in, but hey, that was the best choice.
- austincheney 7y ago
  Speaking of tanks and fallacies... https://www.amazon.com/Pentagon-Wars-Reformers-Challenge-Guard/dp/1557500819/ref=sr_1_1?keywords=pentagon+wars+burton&qid=1558882108&s=gateway&sr=8-1 https://www.amazon.com/Pentagon-Wars-Reformers-Challenge-Gua...
- MaxBarraclough 7y ago
  Not to mention the regulatory issues.
  - lxwang 7y ago
    If everyone just buys tanks, eventually they'll have no choice but to change the regulations.
- astrobe_ 7y ago
  But a tank is so much more powerful.

austincheney 7y ago

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 be correct as many eyes would have found and reported any problems. This fallacy also explains why horrendous highly visible bugs can present in exceedingly popular applications for long periods of time, because developers simply believe the strength and wisdom of the community are enough to identify, report, and resolve any issue in a timely manner. Software isn't magic and isn't magically updated or repaired because its popular. * Invented Here. This is the opposite of the more well known Not Invented Here, which asserts that developers are irrationally afraid to write original code. The common assertion is that any original code whether from you or your coworkers is a horrid mistake, because somebody else has done it better. The common defense is that developers are standing on the shoulders of giants. * Toolsmith Fallacy. This is an extension of the above mentioned invented here fallacy in that use of tools is good and the use of more tools is likely better. This line of thinking is how we end up with stupidity like left-pad and how a simple 30 line tool could have hundreds of dependencies whose total weight exceeds hundreds of megabytes. This fallacy is also dangerous when it asserts that dependencies don't need to be tested since the assumption is that they are better than original code. * Student Fallacy. This asserts that the approach first learned is most correct. This fallacy is used as a bias against differing ways to solve a problem so that a developer can maintain confidence and save face when criticized or encounters something they don't understand. * Big Fallacy. This asserts that when something becomes large or poorly understood it should be dismissed out of hand. This is essentially a bias against reading code, which is the required first step before refactoring any given approach into something more comprehensible. This fallacy completely ignores that fact that a given artifact may do the job perfectly well with great performance. * Framework Fallacy. This fallacy is an extension of the toolsmith fallacy and basically says a given approach cannot be achieved without a given tool if there is a tool that claims to address the problem. * Assembly Fallacy. I have not seen this one in a while, but when jQuery was really popular any attempt to write code without use of jQuery was immediately compared to writing assembly. * DOM is slow. Most people making this claim don't really seem to know what the DOM is. Here is the DOM that modern web browsers use: https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/ This one is highly technical and makes many people sad, so I won't go into this here. * Open Source is a My Personal Gift. This fallacy asserts that free software is a gift provided for you. Open source software, like any software, takes effort of a person writing software. If you want a new feature submit a pull request. It is astonishing to see the hostility that arises when this is mentioned.

tide_ad 7y ago

> 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 to put a disclaimer on that, it just wastes your time and confuses the recipient. Appeal to Authority works.

zzzcpan 7y ago
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.
- tide_ad 7y ago
  > You can't appeal to authority your way into subject experts, they might even openly criticize you for your bullshit. They might, and they might also ignore you without a source because they are so focused on discrediting everyone thats not themselves. > Define works. Gets people to more quickly agree with your line of reasoning, by masquerading your line of reasoning as a non-independent thought and simply finding something that agrees with you on Google. I know that search engines mostly just agree with you. Other people don't.
- BeetleB 7y ago
  >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.

shaki-dora 7y ago

The 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 from first principle. At some point, when the New York Times has an article highlighting the benefits of vaccinations, while @TheyAreTryingToKillYou241234 on twitter says the MMR vaccine will cause your kids to grow a second head, it is perfectly fine, or even necessary, to consider the source of some information as evidence in evaluating it. This mechanism, of evaluating sources of time and establishing trust, is so pervasive we tend not to even notice it. You are far more likely to hand your car keys to your spouse when asked than to a random stranger.

Udik 7y ago
Fallacy fallacy exists: assuming that because a reasoning contains a fallacy, its conclusions must be wrong. They're simply unproven. https://en.m.wikipedia.org/wiki/Argument_from_fallacy https://en.m.wikipedia.org/wiki/Argument_from_fallacy https://existentialcomics.com/comic/9 https://existentialcomics.com/comic/9
zzzcpan 7y ago
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.
- matt4077 7y ago
  So how are you supposed to make an informed choice on vaccination? You can't trust the NYT, apparently, and probably not the New England Journal of Medicine, either? Do you just count the number of sources supporting the different views? That would seem to be some other, equally bad, form of fallacy. Is there any sort of evidence that is valid in your critical eyes that can be transmitted electronically? Or does anyone faced with the choice to vaccinate their children have to run their own randomised clinical trial? That would seem prohibitively cumbersome, and also logically inconsistent because you would have to find a few thousand people willing to participate in your trial who shouldn't trust you not to poison them, by your logic.

Udik 7y ago

No true Scotsman's: - We followed agile methodology and failed miserably. - Then you weren't using real agile.

V-2 7y ago
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.
- humanrebar 7y ago
  Agile is a set of values, not a methodology. You're thinking of scrum or extreme programming or kanban or something more specific.
  - jacquesm 7y ago
    I really hope this was an attempt at deadpan humor given the grandparent of this comment.
    - humanrebar 7y ago
      Nope. The Agile Manifesto is a list of values. There's no method to misapply. The real irony is people claiming to "value individuals and interactions over processes and tools" turning around and telling engineers that the problem is their processes and tools.

afranchuk 7y ago

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?

mgkimsal 7y ago
"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 that is "what makes you think you're so much smarter/better than the previous team?" Well... sometimes I maybe am. Or... the strength of the current team is just... more demonstrable? Or... there's no one left from the previous team that even understands the previous system, so ever day spent is often wasted in just trying to learn what they did, only to find out... hey - they really just had no clue what they were doing. We've all seen this (and, early on, I likely was in the position of the offending party a few times). But sunk cost fallacy is a real thing. How do you combat it?
- akvadrako 7y ago
  Wholesale rewrites often have huge future costs, so I don’t think dismissing them is a sunk cost fallacy.
  - mgkimsal 7y ago
    That's not what I was suggesting. I was suggesting that dismissing any calls for any change (whether it's whole rebuild or any degree of aggressive change) is often justified with "but we've already paid $x for this project". Couple that with then also complaining about further costs just grinds my gears. Probably 1/3rd of the projects I've worked on over the last 20 years were software systems that were objectively/measurable poor, and probably half of those warranted a rebuild, and genuinely not 'flavor of the month' justifications. You can't cheaply and safely, for example, run a business on foxpro/db2, relying on one person in a different country with all the source code, running in a virtualized windows XP environment on Windows server 2000, while also wanting to modify your business processes and grow your business. I'm not saying it can't be done, but the costs and risks outweight whatever benefit you've already bought and paid for the last 20 years.

humanrebar 7y ago

> ...solutions to problems are rejected because they are not perfect... I have seen the flip side as well... dismissing an idea as an instance of "too academic" or "perfectionist" problem solving. It's actually pretty hard to take the time to understand someone's thoughts well enough to differentiate between a complex but real flaw and an aesthetic preference.

diNgUrAndI 7y ago

> 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 are exaggerating or telling the truth. I found someone has the tendencies to elaborate on stuffs in an emotional way. This is especially common in junior devs. From my experience, most senior devs tend to be more reserved and careful about their words. What do you guys think?

robluxus 7y ago
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.

chadash 7y ago

> 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 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 (unless, of course, you are chess master at his level). The same thing is true with software. Some people are really strong engineers with really strong expertise in a specific domain. If you follow their advice within their domain of expertise, you might not come to the optimal solution, but you'll probably come to a good enough solution. Of course, there are exceptions, but in my personal experience, I've seen more people mess up by not following experts' advice than by following it.

shados 7y ago
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, best practices aren't a thing, etc. The second (and part of the reason the first is a thing), is the amount of people acting as experts that really aren't. Even big names and pseudo-celebrities in the field frequently have no idea what they're talking about. Once people realize this, they start questioning everything. And thus, we're stuck in software engineering stone age. Being unable to separate the good stuff from the bullshit is holding us back a lot.
- wpasc 7y ago
  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.

diehunde 7y ago

The problem is that most fallacies have a base on cognitive biases. And even when we are aware of them, they are unconscious. So we can't avoid them. But we can try to mitigate them[1]. [1]https://en.wikipedia.org/wiki/Cognitive_bias_mitigation https://en.wikipedia.org/wiki/Cognitive_bias_mitigation

darekkay 7y ago

If you're interested in logical fallacies in general, have a look at my "Logical fallacy of the day" (via RSS, HTML or JSON): https://tips.darekkay.com/html/logical-fallacies-en.html https://tips.darekkay.com/html/logical-fallacies-en.html

argd678 7y ago

> 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. Despite the stereotype of engineers being logical, it’s more they’d like you to see them that way, but are really maybe just 2% more logical in their reasoning than anyone else.

BeetleB 7y ago
>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)
- nullc 7y ago
  > 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. Winner winner, chicken dinner. Some of these things COULD one day be facts, but essentially no one has done the research to determine the fact form of the opinion. "In code of type X maintained like Y, structure Z has been identified to cause a higher defect rate and increased lifetime maintenance costs compared to ZZ" could be a true fact, but seldom do we have any results from rigorous study. Consistency certainly appears very useful, so appealing to some authorities opinion just to get a consistent outcome is probably a reasonable thing to do in many cases. Unfortunately, many people argue for these opinions by first confusing them for facts and defending them as such. We'd often be better off-- in matters of code style or similar-- if teams were more ready to use and accept arguments of the form "that as far as anyone knows option X is at least as good, objectively speaking, as anything other option and for consistency sake we might as well adopt it since {our industry, our team's most prolific reviewer, our existing codebase, etc.} prefers it".

adrianmonk 7y ago

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.

teucris 7y ago
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.
- pg_is_a_butt 7y ago
  ... 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.

nullc 7y ago

https://en.wikipedia.org/wiki/Argument_from_fallacy https://en.wikipedia.org/wiki/Argument_from_fallacy Increasingly, I've seen being blindly dismissive due to awareness of usually helpful but sometimes harmful cognitive heuristics to be a source of mistakes in reasoning. Human reasoning has a multitude of biases and approximations that evolution has preserved in our behavior. They are not always in our best interest, but nor is our alternative behavior when we try to act to contradict them.

jayd16 7y ago

The Historian's fallacy cuts both way. Often the legacy code is convoluted because there's a subtlety that isn't immediately obvious.

nadocrew 7y ago

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_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...

l0b0 7y ago

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.

enzoaguado 7y ago

Not 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

ukoki 7y ago

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

mxschumacher 7y ago

A millenium lasts for 1000 years. Early versions of brains came about around 600 million years ago.

heraclius 7y ago

I’m not sure how useful fallacy theory is when applied thus. We’re all quite happy to accept induction (well, software engineers probably should be), and so the use of formally incorrect heuristics is not necessarily a bad idea.