Comments on: Watch Your Language!

By: Everyday Tales: Anatomy of a Refactoring at Fragmental.tw

Everyday Tales: Anatomy of a Refactoring at Fragmental.tw — Wed, 24 Feb 2010 12:59:35 +0000

[…] client is a classic example of environment where the business language was derived from the systems language. More than building some piece of software, our work as consultants is to help the client to solve […]

By: I Wish I Knew That Before Getting This Job – Slides and (Long) Notes at Fragmental.tw

Tue, 24 Nov 2009 12:39:20 +0000

[…] to make sure that they speak the same language. Domain-Driven Design can help you a lot with that as it aims to achieve a Ubiquitous Language used for developers, users and everyone else in that […]

By: Sam Aaron

Sam Aaron — Fri, 12 Jun 2009 14:11:25 +0000

I couldn’t agree more

By: Phillip Calçado "Shoes"

Phillip Calçado "Shoes" — Fri, 12 Jun 2009 09:27:02 +0000

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’

By: Joseph Wecker

Joseph Wecker — Thu, 11 Jun 2009 22:23:22 +0000

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.

By: Pat Kolysher

Pat Kolysher — Thu, 11 Jun 2009 20:18:37 +0000

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

By: Jose Donizetti

Jose Donizetti — Thu, 11 Jun 2009 16:21:51 +0000

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.

By: André Faria Gomes

André Faria Gomes — Thu, 11 Jun 2009 13:25:30 +0000

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!

By: Rafael Peixoto de Azevedo

Rafael Peixoto de Azevedo — Thu, 11 Jun 2009 13:12:34 +0000

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

By: John Carney

John Carney — Thu, 11 Jun 2009 12:51:09 +0000

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.