In the world of Computer Systems Engineering we have a tendency to name things in the hardest way possible. We are all guilty of it on some level. As the cognitive load on engineers grows day by day, I’d like to propose that we being to consider naming things in the easiest way possible.

There will be a lot of discussion and personal opinions on this topic. What I am writing is only my personal opinion on things I’ve seen, and ways we can make our jobs a bit easier.

I will be using real life examples in this article, although I will attempt to modify them enough to protect the guilty.

Use Words, Not Numbers

We should never be using or expecting others to use long strings of numbers to access or find anything. Many times in my career I’ve asked how to access a system and been given an IP address. Never do this. DNS was designed for this very reason.

www.google.com is how people find the Google’s web site.
142.250.72.4 and 2607:f8b0:400f:803::2004 is how your computer finds Google’s web site.

/var is how people find a filesystem
60701a90-d459-4418-867c-2d2266d20b89 is how computers find filesystems.

Speci@l Ch@r@cters, Don’t U$e Them

We all know what special characters are for. If you don’t know what they are for, howtogeek has a great write up here.

There is a an extra cognitive load that is added to anyone who has to make sure to escape, or properly quote strings that have special characters in them. Many hours of troubleshooting can be save by just not using them.

That goes for spaces as well. Just don’t use them.

Abbreviations Not Acronyms

Abbreviations are preferable to acronyms. Allow me to make my case.

If I gave you “CSA” as an acronym with zero context it would be nearly impossible for you to determine what it stands for. Even with context it would be tough. If, instead, I gave you the abbreviation “CompSysArch” you would immediately know, or be much more likely to determine that it stands for “Computer Systems Architecture”.

Across an entire organization there can be hundreds of these acronyms. When a person from another team to told to contact the CSA group, they have no idea what that means. To make matters worse, the email DL (DistList) for that group will be called “Computer Systems Architecture. What hope do they have of contacting the correct group.

I know some will argue, and rightly so, that there are so many more keystrokes with the abbreviation. I agree. However I believe the added keystrokes are nothing compared to the cognitive load and frustration that is added when using acronyms.

If you must use acronyms, use only well established ones. If you must make up your own, never, never use and existing one that his established in your industry. I once worked at a place that used RFC as an internal acronym.

Avoid Obvious Redundancies

Avoid redundancies when naming things. This one is best explained with an example. (A real world example):

./webserver/webserver_configs/webservers_seattle

Now I have to ask, what do you thing is contained in this file? Might it be some sort of configuration for a webserver? How many times do we need the string “webserver” in this path before we know that.

./webserver/configs/seattle tells us exactly the same thing, with far fewer key strokes. This goes for anything, not just files. DNS (A records and sub domains), Vault hierarchies, variable names, etc.

Be Consistent Across Systems

We often times need to give names to the same entity in different systems. For instance a vlan may be defined in your IPAM system, configured in your Cloud Management Platform, and configured in your cloud service (VCenter, Proxmox, AWS, etc.)

Be consistent across these systems. If you name your vlan, vlan101 in your IPAM, name it vlan101 in your cloud management platform as well. Again, give it the same name in your cloud service.

This goes for naming literally anything. If you call one datacenter “Charlotte” in VMware, then call it Charlotte across the board. Even in DNS. More on this in a bit.

Naming Order

This one requires some consideration and the answer will not be the same for every organization.

Often times, especially in large environments, we have many things named with the same prefix. An example of this might be a company with a large number of web servers spread across different locations. The naming convention might be something like this:

• web01-seattle.xxx.yyy
• web02-seattle.xxx.yyy
• web01-newyork.xxx.yyy
• web02-newyork.xxx.yyy

There might be hundreds of web servers in each of these locations. When looking through a list, or using some sort of GUI tool to manage some aspect of these servers, the list will be very long. Searching for “web” will produce a huge list were all of the names look the same. Imagine adding 7, or 8 more locations, each with 40 servers, to this. Now the list is huge.

In this case, it might make more sense to name your machines starting with the location. seattle-web01.xxx.yyy. Of course, this may cause an issue in the other direction. Maybe you have thousands of machines that now start with “seattle”. This is were each organization will have to consider it’s own situation and come up with a naming scheme that produces the most efficient lists to work with.

Use DNS for Naming

Use DNS (Domain Name System). It’s right there in the name. We can leverage DNS to help alleviate the issues with “Naming Order”, “Be Consistent Across Systems”, and “Use Words, Not Numbers”.

In the case of Naming Order, maybe create a subdomain for those reoccurring location strings. Call your machines web01.seattle.xxx.yyy.

Conclusion

In the end all of this comes down to two things. The first being to lower the daily cognitive load of engineers and administrators. The second is to make things easier in the development of systems. Whether that’s writing code or building systems that interact with each other.