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 one another.
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.