No, it is not just semantics!

From time to time, mostly when discussing, you will hear someone say “This is just semantics!” implying that a group should get back to topic and not loose itself in details. I really hate that phrase! And let me tell you why.

As I pointed out in my post on communication the content or meaning is one of the key feature of language, some might argue that it is the most important one. And this is where semantics kick in, since semantics is the study of meaning. So how do language and meaning come together then? On a very basic level there is a concept (the signified) described by a word (the signifier). If it’s just semantics, I for my part dare to assume that there seem to be different concepts associated with the same word or different words for the same concepts. And this is something that I think should be sorted out.

Let me give you an example. These days I way discussing with a project manager about our new time recording system. He was proposing to log working time on epic user stories, which I strongly opposed since I felt that these were too small elements resulting in too much waste on allocating your times on different items in that system. Furthermore, epics in my understanding are just large user stories which need to be broken down into smaller parts and therefore not a fixed entity. He didn’t really buy into my objections, but then proposed to call the item a requirement. Since people often confuse requirements and the requirement document, I specifically asked about that and that’s when “This is just semantics” came because he meant the document.

So what happened from a semantic point of view? Let’s break down the three terms epic, requirement, requirements document into semantic feature (which are more or less binary attributes associated with a term). My understanding is this:

epicrequirementrequirements document
single content++-
sentence template+--
INVEST model+--
part of requirement specification-++
superordinate element--+
fixed entity-++

The project manager’s understanding was more like this:

epicrequirementrequirements document
part of requirement specification+++
superordinate element+++
fixed entity+++

I know that these are probably not all semantic feature and even those might be debatable, but I think you get what I mean (pun intended). Not only did he seem to take less semantic features into consideration, but the features all had the same value. I’m not saying that my understanding is the right one (well, yeah, actually I am…), but by talking about we were able to build a shared understanding.

If you are more into prototype theory and prefer visualization over tables, it would look like this (and sorry about the CGA colors…):

My point of view:

semantics2

The project manager’s:

semantics1

Discussing helped pointing out different understandings and establishing a shared understanding, something we should all be striving for. Not bad for “just semantics”, isn’t it?