The first time I heard the word ubiquitous, a sigh of utter and ignorant reluctance went through my mind. I figured that such a beautiful but complex word is absolutely bound to bear an over-complicated meaning to something that perhaps might be very easy. And unfortunately, that killed my interest at the time. Well, having understood the importance of ubiquitous language my interest is gained.

So what does it actually mean? Well, a quick search at my favorite place to look for strange words gives me a hint. When adding the word define: before a word, acronym, abbreviation whatever in google, a search will be done at a number of open dictionaries on the Internet. This is nice since the explanation of the word is given in a number of different contexts which gives me a broader meaning of the word. With this search, define: ubiquitous, 5 different explanations are rendered. The one I choose to show to you is this one:

omnipresent: being present everywhere at once
from wordnet.princeton.edu/perl/webwn

In Swedish I would translate this to “allomstädes närvarande” which is even more poetic I think. However, the English translation put us a bit closer on the map as to an understanding of the word, but we’re not there yet. What is omnipresent anyway? Is there really something that can be everywhere at once? Sounds like something I want to be…

Well, speaking about ubiquitous language, naturally we are talking about a metaphor. And after reading about ubiquitous languages in Eric Evans book Domain Driven Design and having combined this knowledge with my own experiences in software development, the pieces actually fall together.

Ubiquitous language is all about sharing a common terminology between people. This is an extremely important ingredient in how we communicate with each other. Without a common terminology there is no way that anyone can explain anything to anyone else. Or at least it will become a very, very difficult thing to do.

Let me take an example of this. Imagine that you are about to explain to you six year old son how he is to ride his new bicycle. Only that you are not allowed to use any words that actually describe such things as pedals, wheels, and stepping on the pedals. Of course you can always point at the things and call them “thingie” but try doing that as you let go of the bike and let him take off on his own.  Well, he is bound to crash the first couple of times anyway so I guess this doesn’t matter that much…

It is hard to find good illustrative examples, isn’t it? Well, I am working on my imagination in this area.

Anyway, in software development we have something that is called the domain knowledge. This is the core business knowledge that is associated with the application(s) to be built. Each company have their own business knowledge and thus also their own specific terminology for it.

However, unfortunately the same terminology is not always used across the company and towards customers. Marketing people will use some terminology when they speak to customers when they originally sell the terrific idea. Then developers probably name those very same things to something similar in the domain architectural design. Then suddenly, further down the road, marketing renames a domain term to something else much cooler and, u-hu, the developers are doomed… They feel that this name change is just not worth the pain of changing it in the software design also. Especially this is common when we are talking the database with live production data. Ouch, do not touch it, it may fall apart and it is deadly vulnerable, the heart and soul of it all etc… Once this name conflict has occurred, the terminology is not shared any longer. Instead all developers have to map their domain names to what marking people means with the provided functionality. This is an utter source of confusion.

Of course, a name change is not the only reason for a mixed terminology at a company and there are certainly most often more players involved than merely developers and marketing people. Lacking communication within a company or misunderstanding of the domain model is just as common source of a fractioned terminology.

So where does ubiquitous “thingie” come in? Well, the terminology that we use to communicate with each other should be as understandable and sharable as possible to everyone so that the same words for describing domain knowledge are used. Then we have a much better chance of actually understanding each other. Trying an illustrative metaphor again; it means that we could concentrate on fitting the puzzle together with the help of the puzzle images instead of trying to do the same thing merely using their geometrical size. At least this is the sensation I get when working in such a domain at a company.

If you know of and understand the domain model and you are about to explain it to new-comers in the project, then my advice is that you start with explaining the terminology being used in a document. This will make it easier for other to understand the domain since they can start by reading this before they get an explanation of what the applications actually does. Otherwise, you will most likely use specific domain language words in your verbal explanations that they have not have heard of before. This will probably make your audience miss the main points you are trying to get across.

Also, by extracting and writing the terminology you will get a better perspective of the domain that you consider as natural and simple but perhaps is not. Most likely, you will find names that are confusing and duplicate names meaning the same thing. If so, revise the terminology so that it is correct and up to date. Make sure that this is the terminology that is used throughout the company by discussing with people. Then you achieve a ubiquitous language which will let you stay focused on the real problems and how to solve these.