Blog: What Do You Mean By “Arguing Over Semantics”?

“To be honest, I don’t care what these types of verification are called be it automated checking or manual testing or ministry of John Cleese walks. What I would like to see is investment and respect being paid to testing as a profession rather than arguing with ourselves over semantics.”

My very first job in software development was as a database programmer at a personnel agency. Many times I wrote a bit of new code, I got a reality check: the computer always did exactly what I said, and not necessarily what I meant. The difference was something that I experienced as a bug. Sometimes the things that I told the computer were consistent with what I meant to tell it, but the way I understood something and the way my clients understood something was different. In that case, the difference was something that my clients experienced as a bug, even though I didn’t, at first. The issue was usually that my clients and I didn’t agree on what we said or what we meant. That wasn’t out of ignorance or ill-will. The problem was often that my clients and I had shallow agreement on a concept. A big part of the job was refining our words for things—and when we did that, we often found that the conversation refined our ideas about things too. Those revelations (Eric Evans calls them “knowledge crunching”) are part of the process of software development.

As the only person on my development team, I was also responsible for preparing end-user documentation for the program. My spelling and grammar could be impeccable, and spelling and grammar checkers could check my words for syntactic correctness. When my description of how to use the program was vague, inaccurate, or imprecise, the agents who used the application would get confused, or would make mistakes, or would miss out on something important. There was a real risk that the company’s clients wouldn’t get the candidates they wanted, or that some qualified person wouldn’t get a shot at a job. Being unclear had real consequences for real people.

A few years later, my friend Dan Spear—at the time, Quaterdeck’s chief scientist, and formerly the principal programmer of QEMM-386—accepted my request for some lessons in assembly language programming. He began the first lesson while we were both sitting back from the keyboard. “Programming a computer,” he began, “is the most humbling thing that you can do. The computer is like a mirror. It does exactly what you tell it to do, and in doing that, it reflects any sloppiness in your thinking or in your way of expressing yourself.”

I was a program manager (a technical position) for the company for four years. Towards the end of my tenure, we began working on an antivirus product. One of the product managers (“product manager” was a marketing position) wanted to put a badge on the retail box: “24 hour support response time!” In a team meeting, we technical people made it clear that we didn’t provide 24-hour monitoring of our support channels. The company’s senior management clearly had no intention of staffing or funding 24-hour support, either. We were in Los Angeles, and the product was developed in Israel. It took development time—sometimes hours, but sometimes days—to analyse a virus and figure out ways to detect and to eradicate it. Nonetheless, the marketing guy (let’s call him Mark) continued to insist that that’s what he wanted to put on the box. One of the programming liaisons (let’s call him Paul) spoke first:

Paul: “I doubt that some of the problems we’re going to see can be turned around in 24 hours. Polymorphic viruses can be tricky to identify and pin down. So what do you mean by 24-hour response time?”

Mark: “Well, we’ll respond within 24 hours.”

Paul: “With a fix?”

Mark: “Not necessarily, but with a response.”

Paul: “With a promise of a fix ? A schedule for a fix?”

Mark: “Not necessarily, but we will respond.”

Paul: “What does it mean to respond?”

Mark: “When someone calls in, we’ll answer the phone.”

Sam (a support person): “We don’t have people here on the weekends.”

Mark: “Well, 24 hours during the week.”

Sam: “We don’t have people here before 7:00am, or after 5:00pm.”

Mark: “Well… we’ll put someone to check voicemail as soon as they get in… and, on the weekends… I don’t know… maybe we can get someone assigned to check voicemail on the weekend too, and they can… maybe, uh… send an email to Israel. And then they can turn it around.”

At this point, as the program manager for the product, I’d had enough. I took a deep breath, and said, “Mark, if you put ’24-hour response time’ on the box, I will guarantee that that will mislead some people. And if we mislead people to take advantage of them, knowing that we’re doing it, we’re lying. And if they give us money because of a lie we’re telling, we’re also stealing. I don’t think our CEO wants to be the CEO of a lying, stealing company.”

There’s a common thread that runs through these stories: they’re about what we say, about what we mean, and about whether we say what we mean and mean what we say. That’s semantics: the relationships between words and meaning. Those relationships are central to testing work.

If you feel yourself tempted to object to something by saying “We’re arguing about semantics,” try a macro expansion: “We’re arguing about what we mean by the words we’re choosing,” which can then be shortened to “We’re arguing about what we mean.” If we can’t settle on the premises of a conversation, we’re going to have an awfully hard time agreeing on conclusions.

7 responses to “What Do You Mean By “Arguing Over Semantics”?”

Who was it said that most arguments really reflect disagreements over premises, rather than conclusions, and that the premises are rarely examined closely?

I once worked in an IT security role somewhere that didn’t have a shared and coherent definition for the word “risk”. The working assumption of senior management was that a risk was A Very Bad Thing that must be removed. Discussion about the meaning of risk was strongly discouraged. We didn’t understand the meaning of one little word of four letters, and the result was that our whole business model was being undermined.

Semantics is not an argument limited to testers. Developers, product managers, and any other group of 2 or more people have the same discussions. The challenge for us as testers is that we have to get the terminology right not just within our own group, but to communicate with these other groups also. The more clearly we can communicate our findings with the appropriate context and wording for the recipient, the more professional respect we will earn.

As an example, if a VP asks me about testing for a product, what is the clearest and most concise way I can phrase my response? If I’m not clear in my own mind how to say what I am doing, it’s even more difficult to translate it for someone else. A vague, muddled, or incomprehensible answer will cause that person to lose respect for me, my team, and ultimately my profession.

What started as a blog post on “the difference between testing and checking” seems to have splintered into numerous, tangentially related topics. Anyway, the comments below are specific to the topic of “Who cares what you call what”…

A definition is, “A statement of the exact meaning of a word”. A word is, “A single distinct meaningful element of speech or writing”. I’m sure glad that words exist, as they provide me a quick and convenient way of expressing myself!

For example, instead of saying, “I ate the round fruit of a tree of the rose family, which typically has thin red or green skin and crisp flesh”, I can simply say, “I ate an apple”. Thanks, words!

Of course, if I take the “shortcut” of saying, “I ate an apple”, I assume that you and I both understand what an “apple” is. If I understand apple to mean, “the round fruit of a tree of the rose family, which typically has thin red or green skin and crisp flesh”, but you understand “apple” to mean, “a substance that, when introduced into or absorbed by a living organism, causes death or injury”, any subsequent conversation between us will probably be confusing, and could even snowball to disastrous effect.

Someone said, “I don’t care what these types of verification are called.” I suggest that you MUST care. If not, then you are resigned to either A) accepting misunderstandings, or B) constantly communicating using definitions to avoid misunderstandings.

Since “accepting misunderstandings” is a lousy way to go, lets explore how to “avoid misunderstandings”.

In order to avoid misunderstandings, you need to either 1) assume/ensure that you and I both have a consistent understanding of the definition of “apple”, or 2) constantly say, “the round fruit of a tree of the rose family, which typically has thin red or green skin and crisp flesh” instead of “apple”.

Interestingly, I sometimes use technique #2 to achieve #1. If I’m discussing a topic that requires the use of words with contentious definitions, instead of simply using the word itself (which might lead to confusing conversation and snowballing, disastrous effects), I’ll force myself (and suggest to others) to use complete definitions, instead. Over and over and over. This will eliminate any potential misunderstandings between us. I’ll continue to use the complete definition until such time that we can select and agree upon a single word that can represent the complete definition. Then we can continue to converse using the “shortcut” knowing that (#1 above), you and I have a consistent understanding of the word.
Or, stated another way, “arguing over semantics“ installs linguistic guardrails to help prevent people from casually driving off a certain semantic cliff” that results in “software that has been negligently tested”, and ultimately “improve the crafts of software testing”.

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.

Past Presentations

You can find an extensive list of presentations and courses that I've taught, including the slides and speaker notes for many of them, here.

Coming up—let's meet!

Check out my schedule, and drop me a line if you'd like to get together when I'm in your part of the world. If you'd like me to work with you and it doesn't look like I'm available, remember that my clients' schedules are subject to change, so mine is too. Finally, note that some conferences offer discounts—and even if they don't advertise it, maybe we can work something out.

February 28, 2019

Wherever you are!

A takeover of the Techwell Hub #testing channel. I'll be asking questions interactively all day. Find out more and sign up here.

March 6, 2019

Wherever you are!

An online webinar, Higher-Value Checking. This webinar is based on the session of the same name that I presented at EuroSTAR 2018.

April 1-4, 2019

San Francisco, California, USA

The Software Test Professionals Conference (STPCon). I'll be giving two one-day workshops: Critical Thinking for Testers, and a Rapid Introduction to Rapid Software Testing. Then there's a keynote talk on Testers as Their Own Worst Enemies, and a track talk on Rapid Software Testing in Agile Contexts. More information here.

XP 2019 - The 20th International Conference on Agile Software and Systems Development. I'll be offering a one-day workshop on Analysis for Agilists, and a talk on Refactoring the Agile Testing Quadrants.