How to win an argument — software developers version

https://xkcd.com/1570/

“Have you ever found yourself in the middle of an argument and had a strong feeling that something was very wrong with the point your opposition was making, but you couldn’t pinpoint exactly what it was?”

In the last year, I have been obsessively listening to an excellent podcast called Philosophize This (highly recommend). In one of the episodes, the podcaster Stephen West talks about various kinds of logical fallacies people commit when having conversations with friends, family and at work. Now I work in tech, so I thought it might be interesting to see if I can map the fallacies to examples from my day-to-day working in Software Development. In doing so, perhaps, I’ll also be able to explore if we can have better arguments at work using these concepts.

In my experience, people in tech are already quite logical and they unknowingly end up using a lot of techniques we’ll talk about here to tackle an illogical argument. Some do it better than others, because identifying logical fallacies and using defined language around it is not something we learn explicitly. It often remains in the realm of “soft skills” for most of us. The idea here is to formalize these techniques and put a name to the fallacies we encounter, so that the process of having better arguments can become structured, efficient, fast and repeatable by everyone we work with.

I’ll start with discussing only five of the most common fallacies, and perhaps discuss others in future articles. Let’s jump into it.

1. Appeal to consequences

If X, then Y will occur. Y is desirable. Therefore, X is true/good/the right thing to do.

If X, then Y will occur. Y is undesirable. Therefore, X is false/bad/not the right thing to do.

With an Appeal to consequence, someone will argue how TRUE something is by appealing to how much they like the consequences that arise IF that thing ends up being true. However, just because IF something was true and it makes your life better, doesn’t mean that it’s actually true.

Life examples —

1. If God doesn’t exist then there’s no moral accountability. A tsunami of cheating and murder, is that a world you want to live in? Therefore, God must exist.
2. I love building and driving cars, I don’t think self-driving cars are going to succeed so no point investing money in it.

At work, this happens in many forms — for example, when in a deadline crunch, instead saying “let’s do this later”, people say “this is actually not needed at all”.

1. If we do a security review, it will add 4 weeks to our project and delay our launch. So we don’t need to do this review.
2. If we enable checkstyle, builds and CRs will take longer, slowing down all developers. So we should not enable checkstyle.

In another form, when people are not satisfied with the outcome, they try to blame the process and get rid of it. Here’s a more nuanced example — Unit tests don’t help catch all bugs. Therefore, unit tests are pointless. “Not catching all bugs” is the undesirable outcome here and therefore “writing unit tests” is not good.

2. Affirming the consequent

When X, then Y occurs. Y has occurred. Therefore, X has occurred/is true.

Let’s start off with an example — You know that if the cashier down at the grocery store won the lottery, she would be happy. You go down to the grocery store one day, go through her line and see that she is really happy. Affirming the consequent would be saying, Oh she’s happy! She won the lottery!

Here’s how Affirming the consequent goes — you know that if something happened, a specific consequence would result from it. Now you live in a world where that consequence is reality, so you assume that that one thing that would have caused the consequence has happened.

Work Examples —

1. With good design, high quality code and operational excellence, the ticket load on the team is low. Therefore, a team having a lower ticket load must have good design, high quality code and operational excellence.
2. If a company has a bad business model and poor leadership, the stock price will be low. Therefore, a low stock price indicates this company is doomed.

Note that this one is a bit tricky — while we cannot affirm based on the consequence, we also cannot deny based on it. In the second example, low stock price obviously wouldn’t prove that company is great. But the key point is that it also doesn’t prove the other side.

3. Appeal to ignorance

X is true because there is no evidence that it’s false.

X is false because there is no evidence that it’s true.

This one might seem easy to understand and identify, but the way it gets used can be frustrating. While gathering “evidence” is good practice to make sure you are taking data driven decisions, it’s also important to take decisions based on experience, intuition and gut feeling. It’s what the 80/20 rule dictates to ensure we don’t get caught in an infinite analysis-paralysis.

With Appeal to ignorance, the arguer puts the burden on the proposer to gather evidence that might be hard to collect. Take this example — There’s no definitive, conclusive evidence that proves two humble hobbits didn’t go on an unexpected journey traveling on hairy feet to return the ring of power to the fires of Mt. Doom. Therefore, it must have happened.

The root of the argument from ignorance is that we can believe something because it hasn’t been completely disproven yet. When applied on a personal level, this can be a convenient way of believing in whatever you want to believe in, until the end of time. Because now, if we want to disprove something, we need the collective knowledge of the history of humanity to pull from.

Because something is really difficult for them to understand, they assume that it must not be true.

Few more examples-

1. You think the Egyptians built the pyramids? You actually believe that people living thousands of years before the common era could carve, move and set slabs of limestone that large? Obviously it didn’t happen!
2. It’s hard to prove that reusing an existing service will serve all our use-cases. So let’s just build a new one.

It’s also a good trick used by people who will tell you that the “road not taken” would have been the right thing to do, because how are you ever going to prove them wrong? Example —

1. The other design option would’ve been better. What was the architect thinking with this design decision? Related — we don’t know the constraints of the previous developers. They must just be stupid/ less talented.

4. Ad hominem

If you cannot attack X, attack the source of X

Ad hominem is a diversion tactic — when everything else is failing, attack the source of the information. In my opinion, this is a very cheap trick and is typically used when one is winning the argument and the other has no other means left but to go for a low-blow.

Example — “I don’t think it’s a good idea to be throwing your cat off of a second story building!” They might say, “oh yeah, coming from the guy that never had a cat before?”

At work, it’s very easy to mix this up with “earning trust” and reacting based on past evidence. Example— We saw how the delivery on your last project went. We’d rather not go with your design this time. Maybe you need to involve someone else on your team on this.

One could argue that this might be loosely related to the trust this employee has built with his/her last project at work. People might attack the source based on past experiences. It is still, however, not a logical way to prove the incorrectness of an opinion.

5. Appeal to bandwagon

X is true because everyone says it is.

When marketing companies use Appeal to bandwagon, they show you many happy faces consuming the product they are trying to sell, convincing you that if a lot of people agree that it’s great for them, then it’s probably great for you.

Consensus is usually a useful tool to arrive at the right decision. But with Software Development teams, it almost always leads to a sub-optimal solution. This is because consensus will bring you to the “compromised” solution, wherein a Subject Matter Expert will have to make amends to accommodate the views of a novice. Consensus also tries to copy, to do things similar to how others have done it, without taking into consideration how the “others” use-cases might actually be different from yours.

Example —

1. The backend principle engineer agrees with this front-end technology choice, I have a sign-off from him/her. Let’s proceed with this.
2. I confirmed with the rest of the team and everyone agrees.
3. Team X that builds websites uses NodeJS and it has worked wonders for them. Given this recommendation, we should also use NodeJS to build our embedded system.

Conclusion

In an ideal world, we would all be experts at identifying and calling out logical fallacies. We could then simplify arguments with “I think you are appealing to the consequent here”, instead of trying to explain how theirs is an illogical argument from scratch. Such minor improvements in productivity can hopefully help build us logically sound systems quickly.