There's a scene at the end of the film version of Into the Wild, with Chris McCandless in Bus 142 shortly before learning that he has misidentified a wild plant and eaten seeds that likely caused his death. He's reading Doctor Zhivago by Boris Pasternak, and highlights this passage:
The path trodden by wayfarers and pilgrims followed the railway and then turned into the fields. Here Lara stopped, closed her eyes and took a good breath of the air which carried all the smells of the huge countryside. It was dearer to her than her kin, better than a lover, wiser than a book. For a moment she rediscovered the meaning of her life. She was here on earth to make sense of its wild enchantment and to call each thing by its right name, or, if this were not within her power, then, out of love of life, to give birth to heirs who would do it in her place.
I have to start with Into the Wild, because I haven't read Doctor Zhivago itself. (And it's an affecting, memorable scene.) I don't know the rest of the story, so I'll proceed confidently without context.
David McClinton had a go at a list of rules of systems engineering about thirty years ago. (McClinton, David F. "The Unwritten Laws of Systems Engineering." INCOSE International Symposium. Vol. 4. No. 1. 1994.) The primary three rules are: (1) Everything interacts with everything else; (2) Everything goes somewhere; and (3) There is no such thing as a free lunch. Those are good. I won't argue with them. Some of the other ones are OK, but not as good.
If I were writing the rules of systems engineering, I know what the first one would be:
Call each thing by its right name.
In the beginning—of a project, of a design—there is darkness. More or less. And out of that darkness arises thoughts and ideas and concepts, and they start to congeal into more complex functions and systems and experiments, and so on and so on until the thing is done. But the names of the original ideas change over time into the more focused names of the implementation, but not uniformly. A spectrum of names for the same thing accumulates where the One True Name should be. Things get missed or duplicated or confused.
I can feel the pitch of my voice raise when I encounter these issues. Every bag-of-words-where-one-would-do is an invitation for me to go on a crusade to eliminate the extras. You can't build correctly if there's a chance you're misidentifying the parts. You can't test accurately if there's a chance you're going to measure the wrong thing.
I'm not experiencing that problem right now, since I'm seven days into a new role (not systems engineering this time, but systems engineering adjacent), but what I am doing is getting warmed up for action. The best time to collect and establish the right name for each thing is now, before the confusion starts—before the confusion gets worse, perhaps, because there has never been a project of interesting complexity that has existed before the confusion starts.