5 logical fallacies exemplified in a developer world and The Simpsons

Encounter logical fallacies go with the consultant Job, some of these fallacies, however, can compromise the stability of the team and in other cases make its product foundation trembles like Jello. It’s important you’re familiar with those so you can spot them when they occur.

This time I’ll use some real-world examples I’ve heard on my job and I’ll also borrow the satirical lens of one of my favorite animated series to show how some of these fallacies might look like.

Ad hominem is Latin for “against the man”. Ad hominem occurs when someone rejects, criticizes, or disqualifies a person’s argument or opinion on the basis of personal characteristics, beliefs, background, or any other personal aspect irrelevant to the argument. This logical fallacy is not only logical but may also be perceived as an aggressive and disrespectful move.

Example 1: “Of course you don’t know what distributed architecture means, you’re a Jr.”

Example 2:

One of my favorites fallacies to spot is “appeal to authority”, this happens when someone bases his/her arguments upon another person’s opinion just because this person possesses authority or some kind of recognition. Most of the time this recognition is given in a field or situation different from the scenario where the argument lies.

Example 1: “This is the design we should follow for the system because I saw a video of this known expert who happens to work on Spotify and she says this is the way to go nowadays”

Example 2:

Example 3

This kind of argument assumes a proposition to be true because there is no proof that it is false. Lack of evidence is taken to be evidence of absence.

Take one of the best examples I could find, in the video below Lisa Simpson, is trying to pursue her father about the fault in his logic, as she points out he’s having a ‘Specious reasoning’ ( a seemingly well-reasoned argument but fallacious at the end) by assuming the bear patrol is working like a charm keeping the bears away. Here the absence of bears is taken as proof of evidence.

Have you ever happened to you? you encounter a problem and there’s not enough evidence of what could the reason be behind it? Maybe something worked just fine yesterday and, today is no longer the case. What follows is a set of theories and suppositions, one more compelling than the other but on average they all lack the same amount of evidence to sustain themselves. Knowing this kind of argument will put your perspective in a sharper state and probably save you a couple of otherwise wasted time wandering towards a not-viable path.

This fallacy is also known as the “black-and-white fallacy”, “Either/Or”. The scenario where the dilemma occurs has apparently a limited set of only two options, most of the time contradictory, mutually inclusive, mutually exclusive, all together, etc. When there are actually many other options to choose from.

Example 1: Picture a classic discussion between the development team and the product management team.

— PM: We promised to deliver feature X by the end of the 2Q

— DT: Product management changed the priorities at the beginning of the 1Q some of the new ones added to the list proved to be more time-consuming than anticipated.

— PM: Delaying feature X once again will only jeopardize the trust of our investors.

— DT: Delaying the release of other features will also cause the same effect.

Example 2:

Occurs when a weak argument is presented so that another argument looks better.

Example 1: “Framework X popularity has fallen dramatically since last years mainly due to the all unnecessary heavy lifting needed to use, Y in the other hand is not only easy to use but simply newer.”

Example 2:

Dad, Passionate about Code, Agile Advocate, Human.