What should NOT be in a name

Last week I wrote a litle thing on how a naming convention can help:

1. people finding stuff;
2. people using stuff at the appropriate Level of Development;
3. people revising such stuff, and recognising its Level of Development at a glance.

The decision tree of this process was summarised as follows:

It’s a touchy subject, I won’t pretend I didn’t know that, and there was an uprising of people objecting, trying to add stuff, or saying the very same thing I said people tend to say: that code-based naming is a useless repetition of metadata, and you don’t need it anymore because search engines are So Much Better Than Before. Some even mentioned AI as the solution, as predicted.

This week, I thought I’d address some of those objections and draft up a personal list of stuff that I think should NOT find its place in a naming convention. As I wrote last week, every naming should support users in a specific purpose, so there might be purposes that escape me and that will make these elements make perfect sense. I’m keen on being disproven. Up till today, however, every time I saw these elements in code-based naming, they proved to be useless and a pain for users.

So, let’s see.

A brief recap, I’m sure you’ve seen it, but just to be clear, code-based naming is every naming convention (for objects, drawings, models, whatever) that concatenates strings of codes. Every piece of code is usually an abbreviation or a stand-in for useful metadata, and when I say “useful”, I always mean that it should serve a purpose to the user.

Let’s make a practical example using one of the most used and least understood conventions: the one for file names. Why do I say this naming has clients in mind? Well, think about it. What’s the first thing it tells us? The project. It speaks of a high-level target, one that has many projects in portfolio. The second thing is the company that’s sending the file. The supplier, we might say. This also is more useful when it comes to tracking responsibilities than when it comes to getting shit done. While working on a project, the first two things are taken for granted: they’re a fixed portion one drags along for the benefit of someone else. They’re metadata that have no purpose for the day-to-day work of people immersed in the project.

The other levels are often the tricky part. They’re all useful, per se, as long as they support your project breakdown. If you use a naming that specifies Volumes, and your project isn’t divided in volumes, what you’ll get is a part of code that won’t be used. Files will share the first portion, it’ll all be SC1-SFT-XX-XX, and this means you’re wasting a portion of the naming. You didn’t get the point: you’re just complying with a standard you don’t understand.

So, that’s how we get to the first thing that shouldn’t be in a naming convention: portions you can’t meaningfully compile without using the infamous XX stand-in for “generic”. This happens all the time in file and drawing naming when it comes to volumes and levels: an endless string of XXX-XX-XXX because the model and drawing list aren’t tuned into the logic that drove the drafting of the naming convention in the first place.

Another problematic problem of code-based naming is that, as I was explaining last time, the usual trick is that you use codes connected to metadata or, in some instances, the attributes themselves. We made the example of walls, where a code in the name might be connected to the primary material of its composition, for instance.

Now, the question I get all the time is: what happens when the material changes? Isn’t it risky that the user needs to remember to change it manually in the name? Isn’t this just another portion where things might go wrong? It’s a redundancy, the situation where two pieces of information are present in two unconnected portions of the model, and the answer is yes: it’s at risk of making mistakes. This frequently happens with walls in the detailing stage: the wall changes its thickness, the name doesn’t.

And yet, if the thickness is something users need in the name to navigate their day-to-day jobs as we’ve seen last week, and you can’t just remove it because it’s another thing to check: it’s the lazy way, it means prioritizing the BIM Coordinator over the team, making work difficoult to reduce the coordination overload. If you have something useful that’s also a risk, you don’t take the useful thing away: you mitigate the risk. And the way to mitigate this risk might be putting in place routine checks to support the user and catch these kind of mistakes. There’s a useful article on this topic by Paul Wintour on Parametric Monkey.

Now, there’s also a norm that tries to explain how to name objects, it’s the ISO 22014:2024 and it has been brought to my attention that I failed to mention it. While the norm states some good general principles, it’s always worth remembering that it doesn’t give a Bible on which to craft your naming, the tables and appendices are always non-mandatory, and the specific codes will remain project or company-specific.

And then… and then there’s ordinals. I’ll give a cookie to whomever will be able to explain to me why, oh why, if you have ordinals in your object naming you haven’t started a revolution already, that ends with the standards being burned in the cafeteria and the BIM manager tied to a chair.

Ordinals can be of two kinds.

First occurrence: you have your internal wall with thickness 150 mm and that’s all you know about your wall. Then, you start detailing it, and it happens to be a masonry wall. No questions asked. The naming keeps being W-IW-150mm. Then of course another guy arrives, and it’s a plasterboard wall that just doesn’t want to behave like a regular 125 mm plasterboard: it’s 150 mm as well. It might be some extra boards, it might be the structure, whatever. It happens. It’s fine. This means we’re in that stage, as we were saying last week, when we should switch from a naming that supports general products to a naming that supports a more specific stage in the game, even if it’s not the stage when you’ll be able to put a supplier’s name on them. What should happen is that your original wall should become W-IW-M-150mm (M for Masonry), and the new one will be W-IW-G-150mm (G for Gypsum).

1. this is only possible if the standard allows for this degree of incremental flexibility;
2. this means that, one by one, you’ll eventually have to revise all walls in the project to add that extra letter.

Some people dread doing number 2. Now, the problem is that number 2 should be phrased differently. Instead of “you’ll have to revise all walls in the project to add that extra letter”, it should be “you’ll have to revise all walls in the project and add that extra letter”. Revision is something you should be doing anyway, it’s part of the process. What happens instead is that people perceive this as extra work, because the incremental nature of information modelling is yet to be understood, that’s how the first kind of incremental is born: the first, original wall stays W-IW-150mm and the second one becomes W-IW-150mm-2, since your BIM authoring software doesn’t let you have two walls with the same name. Eventually, someone will arrive, thinking themselves to be very smart, and they’ll say “hey: it bothers me to have some walls with an ordinal and some others without it, let’s put the ordinal in from the beginning.” So the first wall you’ll create will be W-IW-150mm-1 and the second one will follow.

What’s the problem with this?

1. no one is able to tell the difference between number 1 and number 2 at a glance, which is the very point of a well crafted naming convention as we stated last week;
2. people are lazy, and they’re often in a tremendous rush to finish their chores, and they won’t want to browse into the wall’s property to figure out, so they’ll create numbers 3, 4, 5 and so on if the last one they find isn’t the one they want, and now you have a problem of duplicates.

The second kind of ordinal, I swear to God, drives me out of my mind. Some standards, don’t ask me why, think it’s interesting for you to know the order in which walls were born in the mind of the designer, so that’s how it goes. Let’s assume the first wall you have to create is a facade wall, let’s say you’re modelling my house and this means your wall will be in mixed materials, masonry and stone, and it will be 90 cm thick. So let’s say it will be W-FW-X-900mm. Now, some standards, ask you to add an ordinal. So you’ll have a W-FW-X-900mm-001. Then you’ll have the dividing wall for the bathroom. You’re in luck because my house is just one big room but I do have a bathroom, there’s a limit to how much you like an open space. The dividing wall is a regular gypsum, 125 mm. This would make it a W-DW-G-125mm but no, sir, it’ll have to be W-DW-G-125mm-002.

Now, do you remember what I said about two walls not being able to have the same name? Well, that’s for your own protection. The software is trying to prevent you from creating duplicates. What do you think happens when someone else steps into a model with dozens of walls, each one nearly differentiated by an ordinal at the end, and needs a wall that already exists? They check the Big Spreadsheet of Ordinals, find that the next one is number 3, and create W-FW-X-900mm-003 even if the facade wall in mixed material 90 cm thick already existed.

So, that’s my top three of things that should not be in a naming convention:

1. generic stand-ins (the dreaded XXX) mean that the standard doesn’t support the actual organisation of the work that’s being done;
2. metadata that’s just a repetition of an attribute and doesn’t support actual work;
3. ordinals of every shape and size.

What’s yours?