Ubiquitous Language Tips

Here are some tips on using a ubiquitous language on your cross-functional team.

Martin Fowler really knows more about Ubiquitous Language and its importance. Here are a few of my tips.

Mean the Same Thing

On a cross-functional team we would likely have developers, product managers, designers, user representatives, project managers, data scientists, operations engineers, etc. Each one of us deals in our set of deliverables, like code, design documents, interface mockups, plans, configurations, etc. The thing that ties us and our deliverables all together is language.

The language forms a common implementation thread through code, our process and all our deliverables.

If we're not understanding each other, it's likely we're talking past each other and need to define some terms.

Use it Consistently

We use this Ubiquitous Language every day. We don't stray from it. We don't reinvent a name for something we've already invented. There is a time for going broad and figuring out what our language will be. But after a decision or a long-used custom or a critical weight in momentum has been reached -- whatever that tipping point is -- use the same language, consolidate, and try not to stray from it.

Use the language in code, in conversation, in documentation, and everything. To deviate is to dilute its usefulness.

Make it Easy and Obvious

Naming things is hard, right. The difficulty is up front, trying to make it easy later. Easy to say. No one will want to say something that's a tongue twister or too long. But the words we choose must also be distinct so that we know exactly what we're talking about. It's not ambiguous. Easy and distinct are counter-acting forces. For one, easy favors short. Distinct is favors long. Choosing good words is an art of balance.

Team-sourced Language

It seems to me that most of the time, language about what we are building originates in the product discipline. It's at early phases when we talk about what we want, what we're building, and the features entailed. Sometimes engineering has a voice in the early design phase. That can be helpful. Sometimes design labels their interface mockups. That can be helpful.

Sometimes language originates in code, where everything becomes concrete. The engineer might be left to decide this. The engineer might mark in the ticket what this feature and its significant parts have been named. This can be helpful. Engineers actually have a lot of practice in naming. Sometimes isoteric, often distinct.

The imporant thing is to create together, make agreements and then use consistently. Say goodbye to Babel and enjoy shared understanding as you work together!