I believe that semantics matter. I do realize not all semantics matter equally. But, still: semantics matter. It’s disappointing when otherwise intelligent people seem to dismiss something simply because they feel it’s just semantics. Let’s talk about this.

I just recently had a conversation with some testers who pulled out the old “don’t want to spend this much time on semantics” card. Even though we had spent, at that time, a grand total of about thirty seconds on the topic. It was extremely disappointing to me, particularly in testers, because, in my view, good testers should have a healthy respect and tolerance for discussing semantics.

We already know that one of the two hard things involves naming things and Michael Bolton has already done a good job dismissing the “it’s just semantics” response.

So instead of me rehashing all that, let’s take a little trip down the rabbit hole.

The Need to Fix Meaning

“I know what you’re thinking about,” said Tweedledum; “but it isn’t so, nohow.”

“Contraiwise,” continued Tweedledee, “if it was so it might be; and if it were

     so, it would be; but as it isn’t, it ain’t. That’s logic.”

— Lewis Carroll, Through the Looking Glass

Many people don’t realize that the above is actually a sophisticated play on words. I won’t bore you with the semantic aspects of this — see what I did there? — but just know that saying “if it were so” is implying “it is (or was) not so.” The point of the phrase is to exploit a deliberate confusion of language, exhibit a bit of circular logic, and come to a definitive stopping point without reaching any sort of useful conclusion.

Hmm. Seems that last bit could have gone in my post about what politics teaches us about testing. You might note that, in that post, I do refer to the “semanticists.”

My point regarding the above dialogue is that it was put in place as a demonstration of the refusal to fix meaning. How so? Because of shifting semantics.

To take another example, the character Jack in Oscar Wilde’s The Importance of Being Earnest is talking with his friend Algernon and in that context we read:

Jack. “Oh, that is nonsense, Algy. You never talk about anything but nonsense.” Algy. “Nobody ever does.”

The characters of Lewis Carroll and Oscar Wilde are always in a struggle to use language to express themselves and communicate meaning, just as happens in any industry. Yet those characters, much like us, have to deal with the volatility of language. This is a volatility that can slowly restrict our ability to attach specific meaning.

In both situations, we see people dealing with language that cannot be trusted. This causes ontological and epistemological problems for the characters in the stories. Good testers — those that have thought about their discipline and become excellent practitioners of it — know that two of our key challenges revolve around aspects of ontology and epistemology. (At least, that was part of my point in About Testing.)

The language we use is how we experience the world. But when we refuse to provide stable meaning by dealing with semantics, not only do we compromise that experience but we allow our notion of truth to be malleable to the point where shared understanding becomes provisional at best, hindered at worst.

So why is this relevant?

This is relevant because you can have entire classes of people that introduce and/or reinforce this very volatility and lead an industry down these rabbit holes. Speaking more locally, you see teams engaging in this practice as well, where the inability to provide a fixed and consistent meaning allows testing to become defocused, not just as a practice but as a discipline.

Let’s consider a few examples.

This problem happens when testers equate Quality Assurance with Testing, as just one example. Or when testers name things, like test repositories, in ways that are not indicative of what those repositories actually contain. Or when testers use ridiculous terms like “QA testers” or QA automation.”

We also see this when testers grace what is basically just pattern recognition with the term “artificial intelligence” and then call what that tool is doing “testing” and further equate that with the testing that a human would do. Or when testers talk about “UI automation” as being executed “just how a user would use the application.”

Does this matter?

The book Thinking-Driven Testing talks about how good testers should display discipline in thinking which means, in part, carefully defining things, using any necessary terminology precisely, and promoting the usage of that terminology consistently and accurately.

Perhaps ironically, that book is subtitled “The Most Reasonable Approach to Quality Control” and I would argue a good discussion there is around the use of the term “Quality Control.” But, to some testers, that would be “just semantics.”

We see the harm that occurs when this discipline of thinking isn’t done and we see it all over our industry or, again more locally, with teams within a company. I’ll reference myself in the Constraints of Testing History:

“I’ve seen testing, as a discipline, becoming more and more dominated by technocrats on the one hand (who want to turn everything into a programming problem) and the deconstructionists on the other (who want to turn everything into a binary semantic debate).”

The key there, for me, was the qualifier as a “binary” semantic debate as opposed to a reasoned one based on the discipline of thinking just mentioned. I also said, in that same article:

“Semantics are important. But not all semantics are equally important. Recognizing that is one of the ways that testers can start breaking out of the current constraints of their history and making sure they not only seem relevant to how the industry is developing but actually are relevant.”

In Testers and Received Wisdom I was cautionary in another way:

“Where a lot of people get hung up is on the notion of the quote simply being a semantic shell game, turning ‘assurance’ into ‘assistance.’ And I get that because while semantics are important, debates about them can get in the way of getting work done.”

I stand by that because I was talking about the possibility of a semantic shell game in particular, where there is a sort of sleight of hand in the use of shifting vocabulary so that meaning can never be fixed upon.

So while it is necessary to be cautious of becoming a semanticist to the point of distraction, it’s a fact that a focus on semantics is necessary to unpack suitcase words or to help us, and others, avoid muddy thinking.

We Always Deal with Semantics

I do realize these problems are by no means limited to testers, but testers are whom I associate with the most and where I see a trend of some experienced testers reinforcing the “just semantics” dismissal in not-so experienced testers, thus helping to set in place bad habits of thought.

In fact, I see this more with the so-called experienced testers than I do with those who are earlier in their careers. And those more experienced testers should know better because we are always dealing with semantics.

Consider that a large part of what we testers deal with is how people communicate when they specify and build complex things. And that involves semantics. We are often looking at how people encoded information, sometimes in requirements, sometimes in code, sometimes in tests. That encoding relies on semantics. As such, it’s dispiriting to see discussions short-circuited by people who think you are dealing with “just semantics.”

It’s easy to dismiss “We’re debating about semantics.” It’s less easy to dismiss when you frame it as such: “We’re debating about the meaning of the words we’re choosing to use and promote to others so that we make sure we are understandable.”