It definitely helps to do so. However, you can choose to not do so if you can justify the benefit from not doing so. I know it's a vague answer, but it's the most precise you can get without making contextual evaluations (including company priorities).
As a simple (well...) example, I worked on the social security platform for the local government. As you may suspect, the legislature and business requirements are built on decades of agreed upon names. Many systems have been in place for more than one generation of developers, so the names have become ubiquitous.
For reference, we speak Dutch in this region, not English.
Software is written in English, even if everyone involved speaks Dutch. It's a matter of good practice. But what do we do with the customer-specific-jargon? Some examples:
- I doubt many people can accurately express the exact legal differences between "civilian" and "citizen". Dutch has a similar distinction ("inwoner" and "burger"), but even translation dictionaries conflate the meanings (since the dictionaries are not written from a strictly legal context).
- If we translate the codebase and use English terms, then we're bound to run into problems. Some developers will put the wrong word into code. Some developers may mistranslate the code when they speak to the client (thus getting back negative feedback that seems like they wrote wrong code, but they really just used the wrong word to describe the intention of the code.
- On the other hand, if we don't translate, it doesn't matter. The developers don't care about the particular word that is used (they could in theory use
Bar and be happy with it), as long as it's used consistently.
- There is a particular legal right that is given to citizens. Its literal translation is "citizen's right". Citizens have many rights, but this one in particular is called "citizen's right".
- If we translate the code base, what do we call this specific right? Its literal name is too confusing in English. Inventing a new name is counterintuitive and will lead new developers needing a dictionary to map the codebase to the analysis.
Even though it breaks the "no mixed language code rule", choosing to not translate domain concept is the better choice here. At the cost of breaking a theoretical rule, it maintains consistent definitions between all involved parties, it helps contextualize the intention of code (as most developers, as citizens, are aware of social security concepts and their intentions).
What's more important here is that we chose the naming that benefits the developers. Our choice was made specifically to make development of the application easier by simplifying client-developer communication (on a topic that's already incredibly complex).
If it's 'creating an SMS Rule', this is pretty unintelligible for our account management team.
This is often where the functional analyst or project owner comes into play. They are usually the translator between client and developer.
If the clients and developers are speaking different languages, get someone to translate on either party's behalf.
If it's 'configuring a custom SMS', we now have a split in the company where two teams use different words to refer to the same thing.
I see your point, but you can't prevent the fact that different words have different meanings in different contexts. That's just how languages work.
For example, "integrate" has completely different meaning to a software developer, a mathematician, or a social worker. That doesn't mean we should all decide to not use the word in the future.
In a way, if you avoid using a word that makes sense to you, simply because someone else has used this word in a different context, then you are creating a "dependency" on the other person's jargon. Ideally, you write your code (which includes naming) without considering non-developers.
I think it's a general professional tip that you always take care to talk to someone while being aware of the context in which they understand you. The same applies here. Understand that the other party understands these words differently, and then avoid ambiguity in communication.
"well, it's OK if they have different names because they're conceptually different things, although they happen to be implemented the same way."
There are many cases where I see this happen, and the decision is often to not try to unify for the sake of unification.
Planet may all have a
string Name property, but that doesn't mean we need to abstract it into a shared concept (e.g.
Planet may have
PlanetType properties, both of which are structurally the same class (
int ID; string Name;), but that doesn't mean they need to derive from the same base class (e.g,
In short: Just because two concepts have a similarity does not mean that is is a shared/common similarity. Maybe it just happens to be similar, without there being an actual connection.
So my problem is: how should our internal UI refer to the action of 'specifying an SMS to be sent'?
If you have two equivalent synonyms, and one of them avoids an ambiguity that the other doesn't, then pick the one that avoids the ambiguity.
If you have two synonyms, but the one that avoids ambiguity is inferior to the other one, then you need to weigh your options. How strongly do your developers rely on communication with the other team?
If their development rests on the communication quality (as was the case for my social security example), then you have a justifiable reason to pick the inferior option.
If, however, your developers don't need to communicate with the other team and can develop their tool just fine, then you pick the name that fits best (even if it is ambiguous to others).