The most important term I learned in the past months is “Ubiquitous Language”: speak the language of your domain everywhere.
The term seems to come from the world of Doman Driven Design. However, the concept behind it is broadly applicable and useful in any software development context. It basically means that we should speak the language of the problem domain we solve in our software not only with the domain experts but also among developers and even in our code.
Lost in translation
What we often see in software projects is that developers have their own terminology for the things in the problem domain, i.e. for whatever the software they build is about. Only when they talk to the business experts they switch to the actual domain terminology, and sometimes not even then.
This is bad because usually the way we speak forms the way we think. Not speaking and not thinking in terms of the problem our software is supposed to solve means we constantly have to translate from the problem language to our own language, losing information and using misaligned concepts.
Apart from the mental energy, this needs that we very well could invest in crafting a solid software, it usually leads to a solution that aligns with our own concepts and language rather than with the problem domain. Software developed that way will ever so slightly miss the actual target, and the users will have to compensate for it. They will have to translate themselves from the solution provided to the actual problem, e.g. by using workarounds or awkward workflows where the solution does not quite hit the mark.
The translation process will also give room for more serious problems, especially when we as developers start to impose our own terminology on the business experts. Using a language that does not match their mental model, it becomes hard or even impossible to see problems in our proposed solutions. Bugs will sneak in and the blaming game will start, simply because we made communication harder than it already is.
Adopt the ubiquitous language
Using the ubiquitous language (or domain language, if you will) is not hard. Developers constantly learn new terminology and concepts – at least we should be – so, learning the terms of our problem domain should be just another day in the office.
The easiest way to start is having a glossary of terms. It should contain a detailed explanation of each term and a distinction from other, similar terms.
The glossary should not only contain those new words we never have heard from before but also terms from the common language that may have a particular meaning in the problem domain. For example, if you are dealing with specialized kitchen appliances, the terms “cooking”, “frying” and “braising” might be way more specific than an amateur knows.
Reading the glossary usually is not enough. We need to have a feedback loop with the domain experts to determine whether our understanding of the ubiquitous language terms is right. We can do this when we talk about the requirements, but also in sprint reviews.
When we use the ubiquitous language, it is important to have only one word for a specific concept, and only one concept per word. Having multiple concepts per word leads to ambiguities, and having multiple words for a single concept leads to confusion whether there is a difference we may not have grasped yet.
The ubiquitous language in code
When we speak and think in the domain language, it is only natural to also use it in our code. It enables us to build a software that is closer to the actual problem it needs to solve, and it makes our immediately more accessible to other developers who – hopefully – also speak the ubiquitous language.
Often enough, developers will feel the need to add terms to the ubiquitous language. Technicalities of the software like UI elements, certain workflows or processes, may need a proper name that does not exist in the glossary and requirements yet.
In such a case, the usual reaction is to simply make up a new name. After all, naming things is what we do a gazillion times a day. But, as we know, naming is also hard. So why not get a little help? We still do not want to impose new language terms on the business experts – remember the translation problem.
So, instead of creating a new term and explanation for it, give the explanation first and then come up with an appropriate name for the concept together. That way, everybody stays in the loop and evolves the ubiquitous language as a team.
Why not call it domain language or business language?
You might ask why it’s called ubiquitous language. Well, that’s just the name that has been established for this concept.
It’s the term from the glossary. It’s the term from the ubiquitous language of software development.