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?

Domain expert: yes, exactly. And I’d like for those numbers to really be real-time. My MARKETING TEAMS should trust that they are up-to-the-minute and not have to refresh the page.

Technical expert: Ok, that’s important. So you want those numbers to refresh automatically, without initiation by a  MARKETING TEAM MEMBER.

Domain expert: yes.

As it turns out, by “feed,” the domain expert meant a real-time count of a metric for an EVENT and MARKETING TEAM. By assuming anything else, we run the risk of introducing at least two bugs in the system:

  1. An over engineered solution – Overproduction, also a serious waste in Lean terminology, can be considered a bug in the sense that the system yields an “unexpected result.” This is not “exceeding expectations,” it’s wasting the customer’s time and money. It’s YAGNI, plain and simple.
  2. A missed requirement – By assuming that the customer wanted a RSS feed, we likely missed the fact that what he really wanted was a real-time count of the data, and one that updated on the screen automatically. By not delivering such functionality, we’ve missed a key requirement and as such, introduced another bug into the system.

It’s common in language for us to use a term that means one thing when we really mean something else. Because we are intelligent and adaptive creatures, we can absorb these ambiguities and inaccuracies in speech without our brains boiling inside our skulls. But computers are different. A computer program is nothing more than a representation, in code, of how a computer should provide a solution to a business-driven problem domain. Computer programs will do exactly what we tell them to do, every time, with no variation. When we misunderstand anything relevant to the problem domain, and then codify that misunderstanding in how we instruct a computer to act, we are introducing bugs into the system.

Every Misunderstanding? Really? Every. Single. One?

Perhaps I’m being pithy and hyperbolic. I’m willing to admit that we might be right by accident, and avoid a bug as a result. The first time around, at least. But what happens when that feature is revisited or expanded upon later? Or what about when the domain expert requests some additional functionality that, had the team properly understood the problem space, would have been a simple extension to functionality, but is now a rewrite? My statement might be pithy, but I would argue that most of us find it to be experientially true.

I’ll admit that this is all speculation; even anecdotal. But it’s been my own experience in the past that even if I dodge a bullet the first time, I can be assured that there are more rounds in the chamber.

The Bottom Line: Misunderstanding, Like Translation, Has a Cost

As if the cost of translation weren’t enough, misunderstandings between domain experts and development teams results in the added cost of bugs in the system. A Ubiquitous Language, while no guarantor of success, places the right emphasis on eliminating translation and cementing understanding, both of which will drive down cost over time.

Next time, I’ll talk about accuracy and relevance, and how the importance of each in problem and solution spaces underscores the need for a Ubiquitous Language even further.

Tagged with:

Comments are closed.

Switch to our mobile site