Ubiquitous Language – Every Misunderstanding, a Bug

This post is the second in a series on Ubiquitous Language and Domain-Driven Design.

Photo courtesy of Lukjonis Bug

Last week, I wrote about the difference between jargon and communication and how, in the context of a software-intensive system, jargon necessitates either translation between domain experts and developers or the creation of a new, shared language that all parties exercise.

Translation is time-consuming and expensive–an increased communication cost that lengthens software development efforts. Creating a Ubiquitous Language has a cost as well–an up-front investment in creating and exercising the language–but that cost is quickly recouped in the increased velocity of the development team.

The truth is that the communication cost incurred by translation has other ripples throughout our systems. The phrase “Lost in Translation” is not only true in cultural language, but in the jargon-filled domains of our customers and clients. When we allow the need for translation to embed itself in our projects, we invite misunderstanding and, as a result, a far greater cost than just the time it takes to mediate between conflicting terminology.

Beyond the mounting cost of translation, I propose that every misunderstanding between domain experts and developers will ultimately propagate into our software as a bug.

Every Misunderstanding is a Bug in the System

Let’s consider this by way of an example.

Our development team is working on an event management dashboard for a marketing company. Metrics are important to this company, because the success of events is measured in impressions, touches and exposure. As a result, the domain expert would like to ensure that the dashboard includes metrics that give the on-site marketing teams a real-time count of relevant information.

Sounds simple? Consider this:

Domain expert: So we’ll need to provide the marketing teams with the number of opt-ins, the number of players in the game, the number of winners in the game and the total number of times the game has been played.

Technical expert: Ok, so each MARKETING TEAM will need to see those EVENT METRICS on their DASHBOARD.

Domain expert: Yeah, and each of those numbers is a feed for each team.

It’s a common occurrence in a conversation with a domain expert to hear terms that are ambiguous, overloaded in meaning or even brand new to the domain expert. In this example, the domain expert has chosen the term “feed” to represent a number on a marketing dashboard screen. To most development teams, the term feed is quite overloaded in meaning. Could the domain expert possibly mean that each number should be an RSS or Data feed? If so, does the expert expect that these numbers will be published to the dashboard, and should also be consumable via a public service or RSS/ATOM feed? Or does the expert mean something else entirely?

The only way to know for sure is to ask. But the truth is, we often don’t. I’ve been guilty many times in the past of not asking the next series of questions. Many of us have, either because we think we understand “the business” better than we actually do, or because we only have two weeks to get our project out the door when we really needed two months.

So we make an assumption. In this case, we assume that the domain expert wants that RSS feed delivered by a fancy RESTful service when the truth is much simpler:

Technical expert: Feed?

Domain expert:  Yeah, a feed.

Technical expert: Do you mean that each number should available for anyone to see via a public URL?

Domain expert: Oh, no. I just mean that the numbers should be real-time.

Technical expert: Ah, ok. And each number will be a count for only that MARKETING TEAM and EVENT, right?

Page 1 of 2 | Next page