Logical Fallacies in Software Development

Fallacies are common errors in reasoning that will undermine the logic of your argument and if you read this article, you will make better decisions as a software developer by recognizing common logical fallacies in your professional conversations.

Ironic, right? I’ve just committed several logical fallacies in an effort to persuade you to continue reading about how to NOT commit them. Truth is, you can’t avoid making logical fallacies. However, you can be more conscious of committing them. So I’m not going to try to teach you how to break down an opposing argument by identifying various fallacies, because committing a fallacy doesn’t mean the underlining substance of the argument is illogical. I certainly don’t want to show you how to persuade by committing logical fallacies — although there is something to be said that you’ve read this far. I want to share with you the common logical fallacies that I am guilty of, so we all can better evaluate the decisions we make from what we consider solid reasoning. Ultimately, I want us all to continually reflect on our opinions and ask ourselves the following question: what type of logical fallacies am I making and how does it influence my decision?

False Dilemma

We can either go with React or we can go with Angular.

This fallacy attempts to restrict the number of options to solve a problem when in actuality there is at least one more viable option. In the example, I presented to my team only two options of starting our greenfield project. Although React and Angular are two front-end frameworks with the largest following, they certainly weren’t the only possible solutions. We could employ a hybrid of Angular and React, we could adopt the increasingly popular Vue, or even bootstrap our own framework.

A rule of thumb, when presented with a finite number of solutions, challenge the assumptions that we are making in order to restrict our options. Why is it that I think our only options are React or Angular? Are those assumptions actual requirements or a mental shortcut I have allowed myself to take to make a decision?

When you begin to challenge the assumptions you’ve created to reach a decision, you’ll inevitably end up with more creative possibilities.

“Only a Sith deal in absolutes.” — Obi-Wan Kenobi

Appeal to Authority

Eric Elliott says we should always employ functional programming over object-oriented programming.

For me, this is by far the fallacy I’ve committed the most. I’ve too willingly accepted expert opinions without questioning how they arrived at a conclusion. It isn’t that I disagree with Eric Elliott, a well-respected expert in the JavaScript community, it is that when I made this claim, I didn’t fully understand why he champions functional programming and what assumptions were made to come to that conclusion. In other words, I haven’t really proven my point by pointing to his statement. I have to fully understand their logic so I that I can argue from that perspective.

Sometimes, the assumptions experts make are different from the requirements of our work. We must be critical thinkers. To do so, we must evaluate the merit of expert opinions on the basis of their arguments and not on the basis of their reputations.

Appeal to Popularity

This library has over 2000 stars on GitHub. We should use this instead of the other library.

Using off-the-shelf solutions to solve our business problems is one of most cost-efficient ways to deliver value. When evaluating different libraries to solve our problems, it might be tempting to go with the most popular solution, arguing that if these many people endorse it, it must be the best choice.

A belief that is widely held isn’t necessarily a belief that is true. Different requirements require different solutions and arguing for a solution based on its popularity stagnates critical thinking and evolution.

There have been instances where I have decided to use a library with significantly more stars on GitHub when another library would have been more aligned with what I was trying to accomplish. Therefore, I should evaluate the libraries I choose by the problems it aims to solve and not it’s popularity with the community.

Appeal to Nature

There’s something that felt wrong about the last solution. This solution feels better.

It’s not always the case that what is natural is good and what is unnatural is bad. Many times when reviewing code, I find myself thinking that a solution is incorrect, because it feels wrong. Thing is, feelings are subjective and differ from person to person. So does the subjective criteria we use to judge code such as naming, syntax, and to some extent, readability. I may feel like a solution is wrong due to unfamiliarity with the pattern, ignorance of the problems, or lack of experience in the domain. One of our biggest pitfalls is to rely on emotions and intuition to reason about how we solve problems.

Don’t get me wrong, I believe that intuition can provide subtle hints as to how to solve a problem, but if we can’t validate our solutions with concrete logic, it’s a fallacious to think that something that feels more natural is indeed the best path. It’s important to evaluate the quality of code based on the logic steps it takes to solve a problem and not the nuances of how it is written, because what feels right to one person is different for another.

Personal Incredulity

It’s too difficult to understand the previous solution. So we should go with this solution.

We should all strive to write understandable code, but we also should remember that the criteria we use to measure the understandability of code are subjective. Just because I have a hard time understanding a solution, does not indicate that it is flawed. It is fallacious to dismiss a possible solution because I have yet to understand how it solves the problem.

The difficulty in understanding a solution has little to do with the quality of the solution and more to do with a knowledge gap. Before we can effectively evaluate a proposal, we must strive to first be on the same level of understanding.

Appeal to Ignorance

Tell me why we should not implement this solution.

This fallacy assumes a claim is true, because there is a lack of evidence to disprove it. The burden of proof always lies with proving a claim. The absence of dissension neither serves to prove nor disproves it. By committing this fallacy, we rule out other alternatives or the possibility that we performed inadequate research to disprove a claim.

In this case, I must prove that implementing my solution will bring distinct advantages. The fact that presently there aren’t any reasons why my solution shouldn’t be implemented isn’t an indication that it should.


Our current pattern is this. We should follow this current pattern.

Patterns are important in creating manageable, scalable code bases. Establishing patterns front-load design discussions and decisions so that future features may be integrated more seamlessly. However, it’s a common fallacy that an existing code pattern or team philosophy is the be all end all of any technical discourse.

This fallacy fails to address the different requirements for the previously established pattern and the current requirements. We iteratively create software, which means there’s always room for improvement. We can either increase or decrease the quality of our code base with every additional commit. It’s detrimental to neglect retrospection of existing patterns when delivering new features. The assumptions that were previously made doesn’t necessarily hold true now.

Appeal to Hypocrisy

That’s a logical fallacy. Which makes your argument moot.

The most important logical fallacy to remember is that an argument reasoned with fallacies aren’t necessarily unsound. It might be easier to learn about common logical fallacies and point them out in conversation to disprove a point, but it is more beneficial to analyze the substance of the argument sans fallacies.

Hypocrisy doesn’t necessarily identify unsound logic. Someone’s past actions or behaviors is irrelevant to the logic of his or her current argument and attempting to discredit an argument on this basis is simply attacking his or her character.

Fallacies Neither Proves Nor Disproves

So now what? In essence, I just told you that committing logical fallacies indicates errors in reasoning for your argument, but committing logical fallacies does not indicate that your claim is wrong. Then why do we care about fallacies?

We care about logical fallacies, because it enables us to identify the flaws in our argument so that we develop sounder reason. It allows us to absorb, without prejudice, the arguments of our teammates and collaborate to prove or disprove claims that lead to decisions.

Knowing these common fallacies have frequently helped me identify the errors in my reasoning and I use it to challenge my assumptions, so that I can more accurately evaluate the merit of my decisions. It helped me be more conscious of the conclusions I draw and effectively, it allowed me to adapt my stance to new information. I hope that it could in some small way help you recognize the common logical fallacies that permeate your lives.