I came across an article recently on common logical fallacies, and it hit me that a lot of these aren't just abstract philosophy class stuff. They're things I've run into time and time again during my years as a database consultant. Clients, coworkers, vendors, even random folks in forums... everyone falls into these traps sometimes. So I figured I'd kick off a little series exploring the most common fallacies I've seen in the tech world, with a few detours through Star Trek and everyday life along the way. Because let's face it - this stuff shows up everywhere.
Let's start off with my favorite: The Straw Man Argument.
A straw man argument is when someone misrepresents your actual point so they can easily knock it down. Instead of debating what you actually said, they twist it into something ridiculous and argue that instead. It's like arguing with a poorly programmed chatbot that's only half-listening.
I've run into this countless times in the computer consulting world.
Let's say I tell a client, "This database would be more stable if we moved it to SQL Server." Next thing I know, they're telling the CEO, "Richard says our current database is a disaster and everything's going to crash unless we spend $10,000 migrating it this week."
Wait... what?
That's a straw man. I didn't say your database was a disaster. I said we could improve performance and stability long-term by upgrading. That's it. But now I'm the guy running around screaming that the server's on fire. Great.
This kind of thing happens all the time when you work in tech. You make a professional recommendation and suddenly you're being blamed for trying to blow up the entire workflow or gut the budget. It's frustrating, especially when the original advice was perfectly reasonable.
Knowing how to calmly untangle those misunderstandings without getting defensive is part of the job. You have to clarify what you actually said and pull the straw stuffing out of their argument.
A great Star Trek example of the straw man fallacy shows up in The Measure of a Man. Commander Maddox wants to disassemble Data to study him, and when Data objects, Maddox frames it as if Data is claiming to be fully human. But that's not what Data is arguing. He's concerned about his autonomy, memories, and identity being lost in the process. By reducing Data's concerns to a simplistic "he thinks he's human" argument, Maddox avoids dealing with the real ethical questions. That's the essence of a straw man: distorting someone's actual position into something easier to knock down.
And if you zoom out even more, you'll start seeing straw men all over the place. Politics. Religion. Facebook comment threads that went off the rails three replies in. Someone says, "I believe in science," and suddenly they're being accused of worshipping Bill Nye as their god. Happens every day.
So here's the takeaway: whether you're talking to a client about their outdated Access database, or you're just trying to have a rational conversation with someone in real life, watch for the straw man. If someone distorts what you're saying into something absurd, pause and walk it back to the actual point. Make sure you're both talking about the same thing.
Otherwise, you're not solving problems. You're arguing with a scarecrow.
Well, mostly correct, except the server example.
Here's the actual definition, although exaggeration or misrepresentation is involved. It's a fallacy in argument, not communication. Picking at nits I know, leave it to a lawyer.
The strawman fallacy is a logical error that occurs when someone misrepresents or distorts their opponent's argument to make it easier to attack or refute. Instead of addressing the actual argument, the person argues against a weakened or exaggerated version of it. This is like attacking a "straw man" - an easy target that doesn't represent the original position. --Google AI
However, it's valid to point out that sometimes exaggeration is valid, even though it may appear to be a strawman fallacy. For example, if you tell me that you will never need anything other than an address in the United States for your software package. As a diligent analyst I will ask, "Well, what do you want to do when your business grows and your first order comes in from Canada or Mexico?" A good analyst is always asking, "What if (exaggeration happens)?"
That's one reason I said YUK to retrofits in another thread. Yes, I know sometimes we have to get something, anything up and running. The ready, fire then aim approach. But then the old saw comes back into play, "If you don't have time to do it right the first time, how will you find the time to fix it?" I deal with this conundrum every development day.
Thomas fair enough, and yeah, I agree the term "straw man" is most precisely used in the context of formal argument. But in practice, I think a lot of us in IT and consulting have seen clients or coworkers distort what we actually said or recommended in ways that function just like a straw man. It might not be happening in a debate setting, but the outcome is the same: they're not responding to your real position.
Like with the server example - I didn't mean to suggest it was a textbook fallacy. It's more of a "feels like a straw man" situation. I suggest a SQL Server upgrade to improve long-term performance, and someone reacts like I said the current system is trash and we need to burn it all down by Friday. That's not formal debate, but it sure feels like they're arguing with something I didn't say.
And you're absolutely right that sometimes exaggeration is valid - I do the same thing when I'm helping clients scope projects (well, when I used to). You have to ask the what-if questions, especially when they're painting themselves into a corner with short-term thinking. That's not a straw man, that's just being a responsible analyst. Totally different intent.
So I think we're actually in agreement - the fallacy is in misrepresenting someone's position to make it easier to shoot down. Raising exaggerated scenarios as part of analysis or planning? That's just good consulting.
Thomas Gonder
@Reply 9 months ago
Richard Yep, we're in agreement on all of it. In political, consulting or legal discussions, I like to go to the two polars, or extremes, when examining a problem or position. Do we give a single mother on welfare every financial advantage available to the rest of average society or do we give her nothing? Then we can work from there to find a solution that is just. This also works in coding. Test the extremes, a big negative, zero and a large positive when displaying numbers (or other things).
For example, I wondered, if in the ADS I was boxing myself in with my use of the flexible autonumbers I created. Considering that I might have 9,999 back-end databases, that limits me to a maximum of approximately 18.44 quintillion records in a single named table across the entire network. For perspective, and knowingly mixing my metaphors, if you went to the moon one millimeter at a time, about 48 million records would fit in each millimeter. Even if each record was only one byte (and we do know that the letter "A" isn't just one byte in Access, right?), I've long since blown out the size limitations in Jet, ACE and SQL server. I'm feeling safe on that decision.
Michael Olgren
@Reply 9 months ago
This is as old as humans have had the ability to reason... In the 5th century BCE you had a bunch of people called Sophists who essentially did nothing but argue in this fashion. So many of the "debates" today, from any "side," use this technique because it appeals to the emotions, to the Intuitionists, who are now king and queen. "Intellectual" is a dirty word.
Sam Domino
@Reply 9 months ago
I need to make sure I read the logs from oldest to newest instead of top to bottom. Its jarring to come into a philosophical
discussion in the middle, especially when my Caffeine Ingestion Index (CII) is < 5! LOL!!!
If you are a Visitor, go ahead and post your reply as a
new comment, and we'll move it here for you
once it's approved. Be sure to use the same name and email address.
This thread is now CLOSED. If you wish to comment, start a NEW discussion in
Captain's Log.