I totally agree with this post (and the ability to convey such an idea in a few paragraphs is refreshing).
Basically, your mind is like a map of ideas created out of all of your experiences. Trying to describe a specific idea in that map with someone else is basically taking two different ideas and merging them. Both the describer and listen will end up changing their map: the idea.
I think a good way of stating this is that no two people speak exactly the same language. Even where simple terminology is concerned, everyone defines the boundaries of meaning in slightly different ways, and attaches their own particular connotations.
Most people will have the 'center' of their understanding of a given concept close enough to those of others' that the general case of communication is almost always satisfied. But in specific circumstances, as the need for precision in meaning increasingly presents itself, so too does the likelihood of an edge case in which understandings don't overlap.
With this in mind, a lot of the process of 'getting to know' someone can be construed as learning their language, in order to enable effective high-precision communication.
Eric Evans' book Domain Driven Design is all about this approach and is one of the best and deepest books about software design. (Disclosure: I worked with Eric for a few years. But that was because of my high opinion of his book and not the other way around.)
Finding an appropriate language/notation for a problem is perhaps the most important step in solving it. But it's also perhaps the hardest. Most software projects don't try. That's one reason most software is a mess.
I thought the example of using a DSL to get as close to the mindset of the customer as possible was a good concrete example.
I think it was also pointed out that even with this DSL, there was still communication errors. However, it seemed easier to fix the misunderstandings because there was a DSL there to fall back on.
> I thought the example of using a DSL to get as close to the mindset of the customer as possible was a good concrete example.
No, "concrete" means that it's something real and tangible. Not just "a DSL" and "a customer", but "a language for the control of a nuclear power plant" and "General Electric" or something like that. Well, a specific company name is not so important, but the industry and what the language's scope was seem extremely relevant to me.
Without actually providing an example, you have no idea what level of abstraction they're working at, and what kinds of benefits and limitations the DSL may have.
I can't remember the exact DSL, unfortunately. But as an example, consider the following pseudo-code:
for($i = 0; i < 100; $i++) {
$product = mysql_query("query_string");
// do something with product
}
or the far more readable:
Products.find_all.each do |product|
product.do_something
end
Of course, this is only the difference between an ORM and database code, but I think you can imagine the difference if you also encode your clients' vocabulary in your models.
The "fun" bits of client work are when do_something has a non-obvious but critically necessary side effect for products with even-numbered SKUs issued in 1997 from the Chilean subsidiary, and this fact is either a) known to one guy who retired last year or b) so blindingly obvious that it never needed to get written down anywhere.
Basically, your mind is like a map of ideas created out of all of your experiences. Trying to describe a specific idea in that map with someone else is basically taking two different ideas and merging them. Both the describer and listen will end up changing their map: the idea.
Really hard stuff to do.