In part 1 of our series, “Thinking Logically about Software”, we took an introductory dive into some core concepts around correct thinking, and how we might begin to apply those techniques to the way we solve problems and make decisions when we code. Today we are going to look at our very first mental bug, the straw man fallacy. To refresh our memory, let’s remember what a logical fallacy is:
Whenever we uncover a bug in our reasoning from the structure of our statements, we call this a logical fallacy.
Said another way, a logical fallacy is committed when our conclusion cannot be rationally reached by the things we said in our premises. A straw man fallacy is an attempt to argue from a misrepresented or simplified version of your opponent’s position. If you wanted to physically knock a person down, you would need to exert a certain amount of force, which may be difficult. Wouldn’t it be much easier to replace that person with one made of straw and knock that over instead? This is where the straw man name comes from. When you commit a straw man fallacy, your simplified or misrepresented version of your opponent’s stance is done with the intent of making it easier to defeat their argument. Since you aren’t actually debating their true position, you only give the appearance of a rational conclusion, not that you have truly presented one. Let’s examine an example.
Kat: “I’d like to use React for our next project as its declarative model has been intuitive for our team on previous projects.”
Matt: “I can’t believe you want to violate separation of concerns by mixing HTML and JavaScript, and Kat wants to make this project unorganized with React.”
Kat presents an argument to use React for their next project, and Matt rebuts the argument with their own opinion. Kat’s only argument was to use React because they find the declarative model intuitive, but Matt tries to dismantle the decision by misrepresenting what Kat actually wants. Matt is implying that using React mixes HTML and JS, while also characterizing Kat’s position as someone who desires a lack of organization. Based on the premises provided here, it is possible for both Kat and Matt to be correct, but that cannot be purely inferred from the arguments, and so does not logically follow. Matt is arguing against a position that Kat did not present and has committed a straw man fallacy; his position can be dismissed if he cannot provide reasonable evidence to back up his assertion.
Straw man fallacies can be quite subtle in everyday discussion, making them hard to notice and call out. If the person you are debating has misrepresented your position, you should make it very clear what your position is and call out the straw man proposed as being fallacious:
Matt: “I can’t believe you want to violate separation of concerns by mixing HTML and JavaScript, and Kat wants to make this project unorganized with React.”
Kat: “That’s not a fair analysis of what I actually want for this project. Just because we use React doesn’t mean we can’t be organized, and I know of some great techniques for keeping React projects well-organized.”
Straw man arguments are also an interesting and special logic tool in that they can be employed in the open to find flaws in propositions. This happens quite regularly in the ECMAScript committee, the standards body behind the JavaScript language. When a change or feature is proposed for the language, this proposal is often referred to as a “straw man”. The proposer stands up this straw man for the committee to try and knock over, and if anyone is successful in knocking it over, the proposal doesn’t move forward. However, if the argument stands, and therefore the straw man, the proposal has the power to move forward into later stages, and potentially become an official addition to the language. This makes “straw-manning” an important utility for poking holes in reasoning when employed with intent.
In conclusion, having the ability to recognize straw man fallacies is important for both having the ability to argue your claim without misrepresentation and to encourage others to find flaws in your own reasoning. Try to keep an eye out for it from others and correct it when noticed, even if you are the one committing the fallacy.