Developer Roundtable - Anything counts as a Scotsman Fallacy

This time during the Developer Roundtable, we discussed an interesting thought Casey had. The opposite of the No true Scotsman. Anything counts as a Scotsman fallacy

No true Scotsman

The No true Scotsman is a type of logical mistake where someone changes the definition or criteria of a general statement to exclude a specific example that contradicts it. Essentially, it’s a way of moving the goalposts to maintain an argument, even when presented with evidence that contradicts it. The example Casey gave was: someone says, “All Scotsmen wear kilts.” If someone else responds, “I am Scottish and I don’t wear kilts,” the first person might retort, “Well, all true Scotsmen wear kilts.” In this case, the term “true Scotsman” is being used to arbitrarily exclude the counterexample, thus protecting the original, overly broad generalization.

This can be applied to software development as well. Most notably, people who are major proponents of scrum or agile development get accused of this fallacy. Someone might say, “Well, my team tried scrum and it just didn’t work.” Oftentimes you will hear a scrum advocate say something similar to: ‘You didn’t use continuous integration correctly, so you didn’t use scrum right and scrum isn’t the issue here.” The counter example is refuted and excluded as viable evidence.

What if we take this a step further?

To take an interesting twist on this idea, Casey proposed the idea that maybe there is an Anything counts as a Scotsman fallacy, fallacy. Rolls off the tongue, right?

Think of this example: I tried Test Driven Development (TDD) and it just didn’t work for me. Therefore TDD doesn’t work and is trash. Basically, take a concept, idea, framework, tool or whatever you are trying and give it a bad try. Like skimming a blog post and then trying to implement it in your app. Because you couldn’t get the thing to work after taking a few minutes to learn, you conclude that the thing is awful and shouldn’t be used.

And, hey, we have all been here. At least I have and it seemed like most of us on the developer roundtable call felt this same way. We misunderstand a concept, apply it lazily and then throw it in the trash. We might even take it a step further and tell others that the concept is terrible and shouldn’t be used.

An interesting example Max brought up can be seen in recipe reviews. Sometimes you will see a review that is scathing. But when you read the review, it says something like “This fettuccine alfredo recipe tasted awful, I would not recommend…..(further down the review)….I substituted almond milk for the dairy”. Well yea, almond milk would be a terrible substitute in this recipe. Doesn’t mean the recipe itself is awful, the way you implemented the recipe was the problem here.

A possible reason why this might happen in the developer world, stated by Casey, is that when we have a new developer starting out, they often run into problems. The common thing to say is “you aren’t the problem, this [framework/tool] is hard to understand or use”. We label problems early on as the tools fault, not our fault. But over time, we need to scale this mindset back and learn to recognize when it’s our fault and when we are using tools incorrectly. Sometimes we definitely are the problem.

I’m sure we all can think of a time when we are on a time crunch for a feature or wake up feeling low on spoons. You need a tool to accomplish something in your app and search the internet. You find something that looks correct and skim the README or some blog post. You cram it into your app and run into a host of problems that are starting to pile up quickly. You might not have the patience and emotional capacity to make this work or maybe you have a time deadline that is fast approaching. Since this tool didn’t seamlessly work, you label the tool as incompatible or awful to use. You strip it from your app and move onto the next. This is not a tool problem, this is a you problem. The conclusion here should be “I am not able to fully learn how to use this tool” instead of “this tool is too complicated or hard to use”. But we often make this conclusion and don’t think twice about it.

Yossef brought up a good point as we were discussing this. For better or worse, with a career in programming, if you are tired or in a bad space mentally, you often will push through. There are no immediate and salient dangers to doing so. But, in contrast, if you are a wood worker, the dangers of being tired are immediate. You have to stop, you need a break or you will regret and potentially face a physical consequence. As programmers, however, we need to be mentally aware of the consequences that coding in a poor mental state can have. We can run into the Anything counts as a Scotsman fallacy. Thanks for the new term Casey!

---

Enjoyed this content? Join our developer roundtable, we meet every other Friday from 10:30 - 11:30 am CT. Hope to see you there!

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.