“No True Scotsman” is an argument pattern. It goes like this:
Bob: "No Scotsman wears a blue kilt."
Susan: "William Wallace wore a blue kilt."
Bob: "Hmph. Well, no *true* Scotsman wears a blue kilt."
Bob tries to make a generalization, a broad claim. Susan provides a counterexample. And then rather than admit, “yeah, there are exceptions to my rule”, Bob counters by adding a layer of subjectivity. If Bob decides who’s a true Scotsman, there’s no way for Susan refute him regarding what Scotsmen are like.
This pattern comes up in software development. It comes up when we can’t agree on our terms, and it comes up when we make broad value claims about things. Worst is when we do both at the same time.
“Agile” is the first thing that comes to mind:
Bob: "Agile is great."
Susan: "My last project was agile, and it was terrible because of x, y and z."
Bob: "Oh, agile is supposed to be about a, b and c, not x, y and z. If you understood that, you'd see that *true* agile is great."
Now replace “agile” in that exchange with “functional programming”. Replace it with “object-oriented programming”. Replace it with “continuous integration”. Replace it with “git” or “distributed version control”. Replace it with “React” or “Angular” or “Knockout” or “Backbone”. Replace it with “Ruby” or “Javascript” or “C#”. “Static languages” or “dynamic languages”.
These kinds of claims are made about people, too:
- “Real programmers don’t use IDEs.”
- “No good programmer would use Visual Basic.”
- “Real programmers understand virtual memory.”
- “Everyone should learn how to code.”
Why do we fall down this hole?
It’s comforting to think that my definition of any of these things is an objective one. It’s tempting to think that people who disagree simply don’t get it. But that’s false comfort. My definition of a term is useless if I’m working with somebody with a different perspective. And my job isn’t to know the term. My job isn’t to build the thing by myself. My job tends to be to work with people to agree on terms and build the right thing together.
It’s comforting to think that a new practice or tool or platform is a magic bullet, the thing to be used in every situation from here on out. A broad class of problems is solved. But that’s false comfort. There will be situations where another tool would be better. And my job isn’t to apply the same technology to every problem. My job is to figure out the right problem to solve and then use an appropriate set of tools to solve it.
Catch yourself saying things like “every”, “all”, “nobody”, “x is great”, “y is terrible”. It means you’re on autopilot, at least a little bit. That isn’t necessarily a bad thing, but it’s something to be aware of.
