The ambiguity of naming

What's behind a variable?

Imagine that there is a discussion between developers: Dylan and Don regarding a variable name in the code.

Rename in your favorite IDE is just a few keystrokes away, so Don agrees to change the name.

Soon there's a new requirement to satisfy - display a date of birth of the user.

Both Dylan and Don discuss how to implement it.

Eventually, they decide to add a new field to the User class.

Because it is just another field, right?

What's behind a feature?

Imagine that in another company, there's a brief sprint planning between Derek and Diego and the product owner, Paul, regarding a new feature to implement.

They talk about Tours service and adding a new functionality to support multi-city local tours.

This company creates software supporting local, guided tours in various cities all around the world.

So far they supported only single-city tours, but now they want to expand their offering.

Couple of sprints later, it turned out that multi-city tours can span more than one day, and people might opt-out for visiting certain cities.

Paul also thought about adding a possibility to pre-order food for tours - initially only for multi-city tours, but then he changed his mind and included both types of tours.

Developers had a hard time adjusting the code accordingly, managing multiple concerns.

What is behind a name?

Many people say a cautionary anecdote: "there are two hard things in computer science: cache invalidation and naming things".

Giving a good name became both a meme on its own and a scary tale to tell around the campfire.

But why is naming so hard?

Is it because a variable name or a class name are ambiguous and hard to read, and then to understand?

Turns out that there might be something more fundamental going on.

We use names to communicate.

We express our thoughts, beliefs, as well as concepts and abstract ideas living in a given area of human of business activity.

But this act of naming is extremely profound for the consequences it brings.

As soon as we name something, we basically create a boundary protecting what is inside from what is outside.

Before, none of that existed - we couldn't point at it and say "this is...".

Let's take User as an example - if we use this label User we create a boundary which splits the world into two: those things that are User and those things that are non-User.

Same with a Tour and other "ideas", or "things".

As if we start with a blank "space":

"a reality" (it should be unbounded, but then it will be "hardly visible")

Then we organize "the knowledge space" by introducing a name:

naming slices "reality" into smaller "realities"

the non-User part is barely considered when we talk about User, but it is there, lurking in the shadows.

In a simplified terms, when a new requirements arrive, we use "knowledge boundaries" to reason about the information we get.

Subconsciously, we "compare" - "is it a User or not?", analyze and decide.

Those names frame our thinking, shape boundaries in which our minds operate.

What happens when we have too few "names"?

We try to organize everything using only those few boundaries.

As with a hammer and nails metaphor, "if you have a User, everything looks like a User."

Naming is framing

Also, it is not just some random and arbitraty names, that we shall use - they need to be meaningful.

Meaningful in a given area of human or business activity.

We need to pull and organize information, from the area we try to provide a solutions for, to create "a common language", also referred as "Ubiquitous Language" in Domain-Driven Design lingo.

And those names/labels, they are not only about "business concepts" - in our industry we come up with something we started naming (yet again, another boundary!) as "language patterns" - like design patterns, architectural patterns, and so on.

Those labels can be regarded as symbols - a representation of something, an abstraction, taking away the unnecessary details.

Of course, we use them to communicate effectively, which is one of its roles.

But as a side-effect, often unspoken, is that they limit our thinking by putting an invisible frame around it.

There was a tiny anecdote we explored in the ambiguity of problems:

Why little fish didn't understand what little crayfish was talking about?

What concepts were missing in its "knowledge space"?

Framing brings the knowledge gravity problem too - each time we label something, one could imagine that there's a "meaning capacity" created.

The more capacious name, the more knowledge it attracts.

In a way, "the more fits in".

This impacts the questions we ask ourselves - "how to add that to User?" or "what is the best way of changing Tour?", whereas we might actually need more names (concepts) or just different ones.

Even if we might be aware that we need to use domain model, we might be limited by the names we use to think.

Technical jargon

There is a constant tension and battles between not adding too much technical jargon and at the same time being precise enough.

Balancing that is quite hard, because we need names to communicate effectively, but at the same time we don't want to create too many "knowledge frames".

Later comparisons and analysis take time, energy, and effort.

All those pointless discussions about whether something is SOLID or not, or whether something is microservices or not, are just symptoms of that tension.

Naming is framing - the more frames we create, the more fragmented our thinking becomes.

And yet again it often comes with trying to compare things (concepts) based on their "being" aspect - while there are other ways, but one needs to change a level or a perspective.

That's why it is important to know many tools, to learn different designing approaches, explore various patterns, and understand the context in which they apply - there are more concepts we can use and the frames are organized differently.

Suddenly, we might stop seeing everything as a database table, CRUD entity, or a service.

"The beauty is in the eye of the beholder", as they say.

So whenever you hear, dear Reader, someone saying "it's just a name, let's not overcomplicate things", remember that naming is framing.

Remember that assigning meaning to a symbol - a name - creates a boundary that can either limit or expand our thinking.

Symbol, name, label - they all relate to something we call (yet another name) - a model.

We want our models to be independent, autonomous and cohesive - all representing what they should emphasize, ensuring clarity and purpose in designing.

And as we discuss models, what about their interactions?

How do "knowledge boundaries" interact with each other?

The ambiguity

Whenever we name, we create boundaries.

Not everything fits neatly to everything we organized - sometimes there are "fluffy" points, gray areas, and borderline cases.

But this, yet again, might be a good diagnostic signal that when observed and interpreted correctly, can help us to improve our understanding of the problem domain.

Additionally, when we hear names like "interface", "service", "module", and so on - are we sure that we all agree on what they mean?

What if your understanding (frame) is "more beneficial" than mine?

How can we compare that?

I bet it's not by actively arguing about what things are or not, but more how they are used, what is their purpose and what role they play.

Levels, perspectives and time might be a help here.

So next time, dear Reader, whenever communicating, designing or just being a human, and ask yourself: