Ubiquitous Language – Accuracy Vs. Relevance

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

Part 1 – Communication Vs. Jargon

Part 2 – Every Misunderstanding, a Bug

In part one of this series, I argue that the prevalence of jargon in the problem and solution spaces necessitates a clear and contextualized language that all project stakeholders actively use. In part two, I discuss the most common side-effect of misunderstandings in software projects: the defect.

Photo courtesy of shaman-j

Perhaps its odd that I’m spending so much time talking about and making the case for a ubiquitous language, especially since the concept receives little intensive treatment in DDD circles compared to the classic building-block patterns and new innovations, such as CQRS and Event Sourcing. A simple Google search on DDD-related blogs, or a quick perusal of the DDD Yahoo! Group will reveal that most of the time and effort spent reasoning about the art of Domain-Driven Design is spent on technical patterns and implementation strategies, as opposed to the “softer side” of DDD: language, context and strategic design patterns.

I recognize that my multi-post treatment of Ubiquitous Language may come off as a “Duh” moment for an experienced DDD practitioner. After all, Evans’ treatment of the idea of language and its importance in the creation of software-intensive systems is concise and well-reasoned, leaving out little in the way of justification. And while my goal is partly to reinforce that justification with some of my own, lesser reasoning on the subject, I also wish to illuminate some of the differences between the language of domain experts and development teams so as to underscore those areas most critical to unify into the new, shared language that Evans proposes. These are areas not covered explicitly by Evans that, in my opinion, can aid the DDD practitioner in the actual hands-on creation of a Ubiquitous Language; something not given in-depth treatment in the book.

To be completely transparent, I believe that Ubiquitous Language holds value even where a project is too simple to necessitate a DDD-style approach.

As such, I discuss communication and jargon in part one to underscore the need to confront domain jargon head on, either eliminating it in favor of alternate terminology, or formally bringing it into the new language. My second post on software defects serves to reinforce the idea that a shared language favors clarity and, as such, tends to result in software that does exactly what it was meant to do.

In this post, I’d like to discuss accuracy and relevance and, through this discussion, point out that the creation of a Ubiquitous Language is not the wholesale adoption of the language of the business, but rather, a unification of key concepts from both domain experts and the development team.

Sundials and digital Watches – The art of Time vs. the science of telling time

Sit in a room with domain experts and a development team for any length of time, and you’ll see one of the key differences between these two groups at play almost instantly. Let’s assume a meeting has been called by a technical project manager. Its purpose is to reason about an important feature for a new piece of software that the team is preparing to build.

As the project manager begins to question the domain expert about the feature, you’ll notice that the manager is looking for information that reveals exactly what should be estimated and built. Call them requirements, use cases, scenarios or user stories; the development team is looking for something tangible to construct. But a close listen to the domain expert reveals that their default behavior is not to communicate what needs to be built, but rather, their general thoughts on how they will use the thing when built. Most of the customers I have worked with over the years want to tell me a story, either about the system they currently have or the one they want me to deliver. That story will reveal some of what the domain expert actually wants to see, yes. But if you’ve spent any amount of time on a software project, you’ve likely had had least one meeting later in that project where the customer asks for something new, or changes their mind about the utility of something you’ve already started building. The domain expert’s understanding of their need evolves and is refined over time.

This is frustrating to most traditional development teams. In many projects, the development team wants the problem domain to function like a digital watch. You tell me the hour, minutes and the meridian, and I can tell you what time it is, as well as whether or not the sun is out.

The reality is often more like a sundial. As long as the sun is out, and not obscured behind a cloud, I can give you a loose approximation of the time, within about 15 minutes.

This kind of attitude annoys development teams to no end. We are of the digital watch. We tend to favor accuracy over elegance. A sundial, to us, is nothing more than a decorative garden piece; perhaps a decent perch. Why use one when we can know exactly what time it is, down to the second, or better?

Accuracy vs. Relevance – Picking one over the other

Much of this, I suspect, has been imprinted upon us by the science of our profession. The computers we program tend to do exactly what we tell them to. Accurate inputs yield consistent outputs. As such, accuracy is of the utmost importance, and when we interact with domain experts and customer groups, we expect accurate information to lay the foundation for the software systems we build. When we interact with domain experts, we pepper them with requirements documents and milestones requiring signoff in an attempt to force them into giving us accurate information.

Contrast this with most of the businesses we serve and support, where historical success is often owed more to relevance than accuracy. Of course, the need for accuracy exists in many facets of a business, but outside of finance and accounting, most businesses change and adapt quickly to address a competitive landscape. They shift to remain relevant, often leaving a legacy of inaccuracy. As I stated in my post on jargon and communication, a cursory analysis of most business domains reveals conflicting, inaccurate, and overlapping information. A businesses ability to move with agility, while often a attribute of success, also creates a wasteland of information that stymies technological innovation.

With two competing ideas sitting at either end of the design table—accuracy as represented by the development team, and relevance as represented by the domain expert—there is often a subconscious push to favor one approach over the other.

If the domain expert possesses the most leverage, relevance wins out, and the development team is forced to manage inaccuracy in its code base. The result is a tangled mess, a digital manifestation of the incomplete, inaccurate and overlapping ideas of the business. Change in any software project should be embraced and expected, and Agile methods are designed to accommodate the need of the domain to refine its needs, but a business-dominated domain can cause the rate of change to become constant, resulting in unproductive thrashing.

If, on the other hand, the development team holds the leverage, accuracy wins out, and the domain expert is forced to propose only those features that can be wholly defined prior to construction. The result is well-architected system with a login screen, role-based security and zero useful functionality. When a domain expert is forced to codify a concept or need prior to engaging with the team, he or she is forced to table those ideas with the most value to the business because, invariably, these are the ideas that change most often as the company evolves.

Combining Value – Creating an accurate, relevant language

Creating a Ubiquitous Language is an approach that preserves the relevance of the business domain, while  encouraging the accuracy needed by the development team. More than simply choosing terms or ideas from one group or the other, a Ubiquitous Language (within a bounded context) creates a new vocabulary that domain experts and developers share to craft a solution that can be accurately represented by the software, while remaining flexible and relevant to the evolving needs of domain experts.

When setting out to create and refine a Ubiquitous Language for your project, keep in mind that your domain experts will provide you with the relevance you need to make your system valuable. As you walk them through your process, watch for valuable ideas, and the inaccuracies that surround them. Work with the domain expert and the development team to refine those ideas into something that the software can support, and document those ideas by creating software and models that expresses those ideas clearly and completely. As the language is created, use it. Map old ideas to new ones, and be disciplined enough to “dogfood” the new language in your conversations and design sessions. As ideas are refined—as they evolve—refactor the code. Keep the system tied to the language at all costs.

Sounds like common sense, right? And yet, it’s the hardest, most vital aspect of any software-intensive system.

At least, that’s my opinion.