It was one of my first days in the job. I was hired to head the development of several products for a media company and my new boss and I went to my first meeting.
The room was full of different types of people. You could tell those who were media producers from the managers and the techies. We were about 15 people in a large table.
The meeting was called because one of the company’s TV channels wanted to produce its own radio station. One of the products I was now responsible for was the company’s radio portal that, theoretically, offered a framework that would allow for new stations to be easily added as required. Of course that this was true only if the new radio had only the features provided by the system. The TV channel wanted different features so we had to think about how to fulfil their needs and still integrate back to the main portal.
During the conversation I did very little but observe people and try to understand the jargon. I had past experience with media companies so I knew some of the concepts they were talking about but some others were completely strange for me. A conversation would be like:
Producer: But what if we link music to the station using the TBRADIOMEDIAFILE? Isn’t it what we do for videos anyway?
Techie: Yep but this won’t work here. TBRADIOMEDIAFILE will need VWMUSIC to be triggered from the media input interface.
Manager: NO WAY! Last time we did that was with TBTV and we still have to patch the whole process every ten days!
As had never worked with video or audio over the Internet before I was pretty sure that they were talking about encoding formats or some other multimedia thing I had no idea about.
It only became clear when one of the techie guys said something like “Wait, it’s better to show you in the diagram” and got from his folder an ER Diagram with tables named like TB_RADIO_MEDIA_FILE and views like VW_MUSIC.
And that was an Aha! Moment. I looked around the room again and saw mainly two kinds of people: those who use the system and those who build it.
When talking among themselves those who use the system used a given vocabulary.
But when talking to the techies they had to translate their business lingo into something that the “geeky guys” could understand.
Of course the communication was extremely problematic. The users didn’t know much about databases, tables or classes and the techies didn’t know anything about radio stations, tunes and ads. All the effort in translating from the business world to the system world wasted at least 70% of that meeting.
What I learned from this is that all systems create a language. Even when your users can’t talk directly to the developers they will be influenced by the language created by the system.
As a quick and dumb example, what comes to your mind if you receive an e-mail and the subject is something like “YOUR HUSBAND IS FOLLOWING YOU!”? Creepy? What if the subject was “YOUR HUSBAND IS FOLLOWING YOU ON TWITTER!”? To follow doesn’t mean in real life the same thing that it means in Twitter-lingo.
The language that your system creates is something really important. Unfortunately we as an industry tend not to pay attention to that. One example is the archaic model described below.
In this scenario we often have a system that don’t talk the user’s language. Translation is required between business terms and actual implementation in the form of class names and other code artefacts.
In my opinion the only way to solve this problem is to acknowledge the fact that your system will spawn a language and that will be used by your stakeholders during the whole life-cycle of the software, and maybe even after the software is gone. Instead of dealing with the problems that arise from it being accidental you should try to build a language that is not only useful for techies but makes sense for the users and other stakeholders. That language can’t be used only by developers, it has to be used by everyone that has a role in that software.
It must be ubiquitous.
I’ve been here many times. Their shared language borrows its vocabulary from developers, and this gives the illusion people on both sides of the exchange the illusion that they are talking about the same thing, but really they are not.
There’s the obvious wastage that happens when the business asks developers to do things that are easy to express in their shared language, but is in fact nearly impossible. Either developers waste a lot of time explaining why you can’t just hook a Hoozjibbet up to the Wotzenfratch and push it all through the Margleflab, or they waste a lot of time trying to actually do these crazy things.
There’s also the not-so-obvious wastage that happens when the business doesn’t even bother ask for certain things because they simply can’t express it in the language, so they assume it’s impossible. This kind of wastage is less visible, but I think it is far bigger.
Great Article, Phillip!
Over the years, I have been in several meetings like this.
It clearly reveals internal organisational and communication dysfunctions.
When IT issues are the focus, I think we have responsibility to help them find a shared meaning.
It’s amazing how much a diagram can help on these situations, playing a convergent role for understanding and communicating. But we must avoid diagrams cluttered up with excessive details and complexity.
Diagrams must be simple and direct to the point. The key issues here are expressiveness and relevance, instead of completeness and preciseness.
I totally agree with you, we must always collaboratively strive to build a ubiquitous language in all forms of expression.
Cheers,
Rafael
Very nice! I also see this sort o situations many times. It’s important to listen to the users and put their words in the software insted of creating ower own vocabullary. Congratulations!
When you are in a project that is been driven by agile principles, you will see the big difference that you earn with the ubiquitous vocabulary. Because as you have a lot of meetings with your stakeholders, with a ubiquitous vocabulary those meetings will be shorter and accurately, because techies and stakeholders understand what each other is talking about.
great article.
Yes, this is one of the oldest hurdles in computers. My first example of this was taught in a class in one of my first year computer classes in university. The instructor described a situation where there was a first person wanting something and a second person who would build what the first person wanted.
The first person (who is thinking of a train to transport his materials from one place to another) says, “I need something that can carry a person from one place to another” - second person thinks of a motorcycle. First person continues, “It’s got to be able to go a long distance and have the ability to move around stationary objects” - second person adds (in his head) a steering column and a large gas tank. First person says, “It’s got to carry material from one place to another” - second person thinks of a couple side bags for groceries and papers and such.
The whole point was that the largest amount of error was in the translation from one type of person to another. Same concept as Philips, different pile!
Now for another good read, check out this article on finding true solutions to problems:
http://www.thehumorarchives.com/joke/Vanilla_ice_cream__car_problems
You’re talking about the well known and studied concept of spending the time to create a ubiquitous domain level vocabulary that everyone agrees on. Probably the best treatment I’ve read is in “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Evans.
Yes, Joseph, I am. That’s why the last link points to a page in domaindrivendesign.org and also why this post is tagged under ‘domain-driven design’
I couldn’t agree more