Jay Myers, Software Engineer
August 10, 2016

The author of this blog post gives us a lesson in the concept of ubiquitous language, and the differences between the way programmers speak to each other versus how they communicate with their customers.


man talking jibberishLanguage is important. It’s the main way in which we convey intent, meaning, and purpose. If you’ve ever watched television or a movie from, say, the UK, as a US English speaker you’ve probably run into a couple instances of ambiguity or of overlap between two systems of language. While it’s true that both the UK and the US use English, they are still different in many ways. For instance, the first time you heard someone say “open the boot” as a US English speaker you may well have been confused. Eventually you probably developed your own mapping between the two systems which no doubt allowed you to get a bit more out of your viewing of these shows and movies, but they are still different.

This example is a pretty simple and straightforward kind of mapping – it’s not very complex. But assume that you were dealing with languages between which there wasn’t a simple and direct mapping. My favorite example of this is probably the German word schadenfreude. This incredible word is literally translated to something like “harm-joy” but really means “the feeling of joy or pleasure when one sees another fail or suffer misfortune.” There are tons of examples of words like this. Words which succinctly convey a concept in one language, but require a relatively long and complicated explanation to be understood in another.

Why am I talking about this? Because I want an interesting way to introduce the concept of ubiquitous language. Basically, this is the idea of developing a shared language between software developers and business folks / users. It’s something that seems obvious but is often overlooked. I’ve certainly been a member of a few teams in which the language used internally among developers is decidedly not the same kind of language used when communicating to product owners or users.

Developers tend to use abstractions when talking about the software we are writing. It’s often more comfortable for us to deal with hash tables and arrays rather than testlets or exams. But that’s somewhat counter productive. See, we end up using these abstract and general developer terms in the code that we write, and it seeps into our brains. And then that’s how we think of them – not as the actual concepts they’re supposed to represent, but just as collections of data.

But who cares? I care. And you should too. I don’t like cryptic code, I like straightforward and understandable code. It makes me happy when I write code that anyone can understand without having to know much about the language in which it’s written. It means that I can talk about the software I’ve written to product owners without having to translate it for them and run it through my own filter. Honestly, I don’t trust myself to be accurate enough to convey every single nuance.

I won’t get into my thoughts on writing easily understandable code here (there’s too much to talk about and I’m not an expert), but I do think that at a minimum it’s important to understand that names matter. Not for people (that’s just cruel), but for concepts and code they matter an awful lot.

FOOTNOTES:
1. Schadenfreude: http://en.wikipedia.org/wiki/Schadenfreude
2. Ubiquitous language http://martinfowler.com/bliki/UbiquitousLanguage.html
3. Hash tables:  http://en.wikipedia.org/wiki/Hash_table
4. Arrays: http://en.wikipedia.org/wiki/Array_data_structure
5. That’s just cruel: https://www.youtube.com/watch?v=SKuT6Z3q2KQ

Jay Myers, Software Engineer
August 10, 2016

The author of this blog post gives us a lesson in the concept of ubiquitous language, and the differences between the way programmers speak to each other versus how they communicate with their customers.


man talking jibberishLanguage is important. It’s the main way in which we convey intent, meaning, and purpose. If you’ve ever watched television or a movie from, say, the UK, as a US English speaker you’ve probably run into a couple instances of ambiguity or of overlap between two systems of language. While it’s true that both the UK and the US use English, they are still different in many ways. For instance, the first time you heard someone say “open the boot” as a US English speaker you may well have been confused. Eventually you probably developed your own mapping between the two systems which no doubt allowed you to get a bit more out of your viewing of these shows and movies, but they are still different.

This example is a pretty simple and straightforward kind of mapping – it’s not very complex. But assume that you were dealing with languages between which there wasn’t a simple and direct mapping. My favorite example of this is probably the German word schadenfreude. This incredible word is literally translated to something like “harm-joy” but really means “the feeling of joy or pleasure when one sees another fail or suffer misfortune.” There are tons of examples of words like this. Words which succinctly convey a concept in one language, but require a relatively long and complicated explanation to be understood in another.

Why am I talking about this? Because I want an interesting way to introduce the concept of ubiquitous language. Basically, this is the idea of developing a shared language between software developers and business folks / users. It’s something that seems obvious but is often overlooked. I’ve certainly been a member of a few teams in which the language used internally among developers is decidedly not the same kind of language used when communicating to product owners or users.

Developers tend to use abstractions when talking about the software we are writing. It’s often more comfortable for us to deal with hash tables and arrays rather than testlets or exams. But that’s somewhat counter productive. See, we end up using these abstract and general developer terms in the code that we write, and it seeps into our brains. And then that’s how we think of them – not as the actual concepts they’re supposed to represent, but just as collections of data.

But who cares? I care. And you should too. I don’t like cryptic code, I like straightforward and understandable code. It makes me happy when I write code that anyone can understand without having to know much about the language in which it’s written. It means that I can talk about the software I’ve written to product owners without having to translate it for them and run it through my own filter. Honestly, I don’t trust myself to be accurate enough to convey every single nuance.

I won’t get into my thoughts on writing easily understandable code here (there’s too much to talk about and I’m not an expert), but I do think that at a minimum it’s important to understand that names matter. Not for people (that’s just cruel), but for concepts and code they matter an awful lot.

FOOTNOTES:
1. Schadenfreude: http://en.wikipedia.org/wiki/Schadenfreude
2. Ubiquitous language http://martinfowler.com/bliki/UbiquitousLanguage.html
3. Hash tables:  http://en.wikipedia.org/wiki/Hash_table
4. Arrays: http://en.wikipedia.org/wiki/Array_data_structure
5. That’s just cruel: https://www.youtube.com/watch?v=SKuT6Z3q2KQ