Monday, 12 October 2009

Avoid Synonyms in the Ubiquoutous Language

Dear Junior

When walking the round trying to establish a new term in the ubiquitous language of a system, it is very tempting to start accepting synonyms.

Perhaps we tried to make 'username' explicit in the model. We then need to settle what a username is, and how it is checked against its validation rules. Among the programmers, we have used username. When we get over to the GUI designers they tend to talk about it as the handle. Later on we find out that the tech writers dig the term alias, and that is what they have used in the manual. It might seem tempting to say we all mean the same thing, so lets accept these as synonyms where after we write three entries in our glossary

username, …”,

handle, see username, and

alias, see username.

So, is that so bad? I guess we can handle three words meaning the same thing. Well, the problem is not the single words, it is the language and in the combinatorial explosion.

We also need to define what we call when we control that a username fulfils the formatting rules. It turns out that we preferred validate, however those that were on the Gazunga project (disregarding department) seem to prefer checkup. Let us accept these as well and add to our glossary

validate …”, and

checkup, see validate.

Even if each word have a very limited number of synonyms, we now have lots of synonyms for phrases (remember that when a glossary is about words, the ubiquitous language is about phrases). There are six synonym prhases for validate username.

  1. validate username
  2. validate alias
  3. checkup handle
  4. validate handle
  5. checkup alias
  6. checkup username

Further on, the user account are by some referred to as pref-set (preference setting space), and by some as area (as in private work area). So, now there are no less that eighteen ways to phrase validate the username of the account.

Et cetera, you get it.

So, letting synonyms into the ubiquitous language quickly leads to having not one language, but a lot of dialects that quickly drift apart to form separate languages and the ubiquity is gone.

Of course there are occations when you have to accept synonyms. If there is an established terminology outside the project there is a point in adhereing to it but what to do if there are several competing standards. For example, the finance department might want to use the accepted term imbursement, but the marketers insist that the established term in our customer base is money-forward both fully acceptable external bodies. In these rare cases we have to accept synonyms, but I still advice to denote either of them as the primary term, and only use the other when necessary. In the glossary it might say money-forward (aka imbursement), a payment made by in exchange for (imbursement preferred by finance department).

By all means, do use synonyms when they are absolutely necessary, but be very restricted. I promise, if you allow synonyms at an early stage, then confusion will arise somewhere down the road.



ps When trying to avoid synonyms you in many ways have the same mind-set as when establishing a canonical data format in the model - but you work in slightly different areas.