Naming is hard?

One of the more difficult problems in software development is “naming.”

As the adage goes: “Naming is hard.”

We really have two different problems:

• What things should we name?
• What name should we give to the things?

Based on the work by Saltzer, we can see the guide to the first question is that:

• Naming should be aligned with the ability to preserve identity.

That is, to preserve identity under some set of changes. Or, worded differently, to borrow from John Day’s synopsis:

The names given to objects must be invariant with respect to some property across the appropriate scope.

In other words, the name must hold true even if the thing is moving around to some degree.

Interestingly, this concept shows up in another area in animal and human development. Notably the concept of “object constancy.” That is, the observer must be able to identify that the object is the same object even though the observer’s viewpoint has changed, or the object itself was temporarily obscured from view. That is, the “sense” of this being the same object must remain invariant under movement and observation changes.

Linking this to the issue of naming, we could then say that the there must be sufficient object constancy to warrant giving the object a name since its identity is invariant under movement and observation changes.

Leading us back to the start, “naming is hard.” But, if we first acknowledge that we need to understand the invariants in question, then it becomes easier to name things.

In software systems, for example:

• A running service is the same irrespective of the network link being used to access it.
• A running service is the same irrespective of the number of intercommunicating backing processes used to ensure scaling and reliability.
• A running service is the same irrespective of the cluster to which it is deployed, based on resource availability.
• etc.

Therefore, the service name should:

• not include the name of the network point-of-attachments involved.
• not include names or references to the underlying processes involved.
• not include the name of the location where it is currently running.

Once we understand the things that are not included in the name, it becomes easier to clarify the scope and pick a name.

Now, we are just left with the other difficult naming problem, “what” name to choose.

References

• Patterns in Network Architecture, John Day.