
Logical fallacies in software engineering - gentleterror
https://artur-martsinkovskyi.github.io/2018/logical-fallacies-in-programming/
======
chadash
> _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
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
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.

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

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

~~~
hobs
Also - make sure they understand your goals instead of your hyperspecific
question - a lot of time can be saved by avoiding the XY problem.

[http://xyproblem.info/](http://xyproblem.info/)

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

~~~
MaxBarraclough
Not to mention the regulatory issues.

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

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

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

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

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

~~~
zzzcpan
In simple terms I'd say there are authoritative opinions and there is evidence
presented by authorities. You may trust some authorities to provide you with
all the necessary evidence to form an opinion, seek evidence from multiple
independent authorities, etc. and form an informed opinion. But you cannot
trust an authoritative opinion in a newspaper. Newspapers exist to make people
trust them, to appeal to authority so they can influence people's opinions
arbitrarily any way they see fit and sell that influence, pretty much
guaranteeing you are not exposed to an informed opinion.

~~~
matt4077
I don't quite the distinction you're making. A paper being published in a
reputable journal is almost by definition relying on its authority. Even if
they allow you to download the underlying data, it won't contain any personal
identifying information of trial participants that you could verify.

> Newspapers exist to make people trust them, to appeal to authority so they
> can influence people's opinions arbitrarily any way they see fit and sell
> that influence

That just reads like some conspiracy theory. Newspapers get people to trust
them by being reliable. I don't need to evaluate every single story they run
when I have done so with some subset and usually found them to be correct.

~~~
zzzcpan
> Even if they allow you to download the underlying data, it won't contain any
> personal identifying information of trial participants that you could
> verify.

Yes, that's a problem. That's why you need multiple independent authorities to
get to a usable level of trustworthiness of information.

> Newspapers get people to trust them by being reliable.

If you are an expert in any subject newspaper reports on, you should be able
to find plenty of evidence that it doesn't report anything how it actually is
from your expert opinion. Best case it reports one tiny thing correctly and
ignores all other facts important to make an informed opinion.

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

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

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

~~~
BeetleB
>Widely repeated, yet wrong.

Not right, either.

Personally, I wouldn't inherit from a class that didn't have a virtual
destructor unless I had a good reason. The point isn't whether it is right or
wrong. Stating it as wrong is as problematic as stating it as right. The point
is that whether it is OK to do it or not is an _opinion_ , not a fact, and
should be discussed as such.

~~~
blt
you are right, I was trying to say the "never" part is wrong but of course
there is a good reason behind the advice; it's not pure bullshit.

------
johnr2
"both at perception, dexterity and mind work"

Off-by-one error ;-)

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

~~~
wolfgke
> 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).

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

------
wazanator
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
Appeal to authority - mentioned in the article.

~~~
MaxBarraclough
It's not strictly identical, as it introduces ageism.

~~~
tirumaraiselvan
True. But age is used as a good proxy for determining authority.

------
afranchuk
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
"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
Wholesale rewrites often have huge future costs, so I don’t think dismissing
them is a sunk cost fallacy.

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

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

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

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

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

~~~
marcosdumay
Git sucks on many different ways. It's also great (much better than Hg) on
many other ways.

So, you'll see people fully convinced that each one is superior, and both are
justified.

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

------
Udik
No true Scotsman's:

\- We followed agile methodology and failed miserably.

\- Then you weren't using _real_ agile.

~~~
V-2
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
Agile is a set of values, not a methodology. You're thinking of scrum or
extreme programming or kanban or something more specific.

~~~
jacquesm
I _really_ hope this was an attempt at deadpan humor given the grandparent of
this comment.

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

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

------
nadocrew
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...](https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

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

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

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

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

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

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

------
hestefisk
404?

~~~
progval
[https://artur-martsinkovskyi.github.io//2018/logical-
fallaci...](https://artur-martsinkovskyi.github.io//2018/logical-fallacies-in-
programming/)

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

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

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

