Ubiquitous Language – Communication Vs. Jargon

Words have meaning. Language is important.

These statements are true, and we tend to pay them their proper lip service in both life and in the realm of software development. Sometimes, we even recognize the importance of language in software, and we seek to canonize our internal vernacular through the creation of lexicons, data dictionaries, service catalogs, SLAs, OLAs or wikis.

More often than not, though, these artifacts serve more as historical proof of our best intentions than as living documents that anchor a software development effort. The canon of our language, at least as represented on paper, falls out of phase with the realities of our software and, as a result, collects dust, only warranting mention when someone on the team recalls how useful such a resource might have been to resolve their current struggles with ambiguous and conflicting knowledge.

We know that language is important in software, or we’d never spend the time early on in our efforts to tame it. But do we know how important it is? Do we believe that success in codifying a language is key to success in the creation of a software-intensive system?


Let’s consider the difference between Communication and Jargon. Communication is the art of using language to convey meaning consistently and clearly. The goal of communication is shared understanding through unambiguous meaning. Consider the following:

Domain expert: When a check payment is sent in, we need verify that the check is legit and then send it to the bank for processing.

Technical expert: What makes it legit?

Domain expert: Valid routing number. Valid account number scheme. And it has to have a signature.

Technical expert: Ok, so we check to make sure those things exist. Then we send to the bank.

Domain expert: Yeah, though I think they only process once per day. So can we hold onto these and only send them once a day?

Technical expert: Sure. We’ll collect these in a batch and fire them off at a set time each day. When do they process?

In the conversation above, the domain expert is attempting to explain a set of needs in their area of concern, the problem space. The technical expert is attempting to understand those needs–the nouns and verbs that “make up” how the domain expert delivers value to the business and their customers—and frame them into how technology will be brought to bear to better enable the domain expert, or the solution space.

Because shared understanding and clarity is a prerequisite to working software, communication is key to the success of any software-intensive system. Clear communication speeds up the creation of working software.


Jargon, on the other hand, slows it down.image

Jargon, a style of communication, is the practice of using certain words and phrases in a way that assumes known context, and thus, can serve as a shortcut in communication. When both parties have a shared understanding of the terminology in play, jargon serves as a valuable shortcut for individuals short on time (read: everyone). The propensity of technologists for three-letter acronyms (TLAs) illustrates our tendency towards and the value of jargon. When it works, it works well.

The problem is, when it doesn’t work, it fails miserably. It necessitates translation, clarification and it slows down the whole process of communication. Here’s an example:

Domain Expert: We need to make sure that our support staff can change the rules that we use to create policies for customers.

Architect: ok, so we’ll use a Strategy pattern and make that config-driven…

Developer: we could just use IoC, build strategies for each implementation and let the users swap out implementations whenever they need to change them.

Architect: That’s an option too. We’ll figure it out offline.

Page 1 of 2 | Next page