A long time ago I co-authored an article with Mat Wall about the value we found from domain-driven design (DDD). That is a way of capturing in software the concepts in our stakeholders’ heads, so that our systems can evolve predictably along with their view of the world.
But DDD is centred around object-oriented systems, and recently I found myself working with a development team whose technology was not object-oriented. Nevertheless, I soon found myself advocating one of the core concepts of DDD: the ubiquitous language. This is the idea of using the same words as our stakeholders, not just to speak to them, but coded into our systems.
The team was facing a small problem of having two categories of customer in the system which were very closely related—confusingly so, in fact. To some it seemed like a technical annoyance which they should tidy up. But then the question became: what was the correct definition? Even if the team agreed on a definition, would it be the same definition as those in the rest of the organisation? In fact, was there even agreement among the rest of the organisation?
It turned out there wasn’t good agreement elsewhere—it was a fairly fuzzy concept that people were still accepting of—and that was starting to show when people were asking for system reports about customers’ activity, and then making decisions based on those reports. What started out looking like a technical annoyance was actually a reflection of a much wider problem, with implications for business decision-making. We could resolve this problem, but it involved bring people together from across the organisation and asking ourselves awkward questions.
There is a higher level lesson here, away from development teams and software. Across different areas of an organisation we need to maximise how much our language overlaps. The solution is not translation—from tech-speak into marketing-speak, for example—but about speaking a common language. That allows genuinely collaborative working, and therefore the optimum results.