Language is tricky. Take the this post, for instance. It’s not about language
problems that are ubiquitous. It’s about problems related to Ubiquitous
Language — whether the problems themselves are ubiquitous or not.
Ubiquitous Language is a term from the Domain-Driven Design software
development practice. It refers to a set of well-defined project terms shared
by all participants: Domain experts, business analysts, developers,
users. The term was coined by Eric Evans in his DDD book. I haven’t
actually read it, but the idea seems sensible: If developers live and breathe
the domain by speaking its language, their output is more likely to fit the
business needs, and developers and domain experts are more likely to understand
As a business analyst and developer, your task is to adopt the language of the
domain experts, not the other way around. But that doesn’t mean that the
domain experts are home free. Changes are probably required to turn their
jargon into a well-defined set of terms that will ensure precise and
unambiguous communication in the project and to the users. Here are some of the
challenges I’ve encountered in this process.