I am getting more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are definitely important, but if the communication fails then the rest is just painting the corpse. From that point of view, getting the language right is one of the key steps for any software project, because the language provides the foundations for all communication. The right language does not, of course, guarantee that the correct thing will be built on time and within budget — but the wrong language is practically a guarantee that the project will fail.

The importance of a common language is nothing new or specific to software projects. The western civilisation has been learning that complex projects have no chance of success without a common language at least for the last two thousand years, but it seems that we have still not taken that message seriously. In the software world, the language of projects has been getting much more attention recently, especially due to Eric Evans and his book Domain-Driven Design: Tackling Complexity in the Heart of Software. Evans coined the phrase Ubiquitous language to describe the best practice to fight different jargons on project teams. Using an ubiquitous language requires business analysts, customers and programmers to all have the same names for the same things. But getting everyone to use common phrases is just one part of the puzzle.

I have stumbled upon a few very interesting conclusions about the language and how important it is to choose good metaphors and names in Douglas Hofstadter’s book Gödel, Escher, Bach. That title has intrigued me for a few years, but as a quick look on Amazon told me that is has almost 800 pages, it had to wait for me to change my daily routine before I could even start reading it. The last few months have been much more quiet than usual, so I finally had some time to dive in. Although the book deals with something completely unrelated to software projects, it contains some very interesting ideas that we can apply to improve software development. I especially like the thoughts on how humans understand formal systems and how the meanings of abstractions form in our minds.

Before this starts to sound too philosophical, let me change the direction of this story. I was recently involved in a project where the common language was chosen and agreed upon, but caused a lot more confusion then I expected. Even with the definitions written down and published on a wiki site, a lot of time was wasted on misunderstandings of basic concepts and going back to explain the same things over and over again. The phrases of that common language were OK from the aspect that they made sense, but they were a compromise between business jargon and technical design and somehow fell short of pleasing anyone. It was a strange situation because all the people involved were techies, and I expected that people with technical education should generally be OK with abstracting things a bit, understanding and using formal definitions even if they do not necessarily bear the same meaning as in common everyday language. But that has not worked out as expected. I had a feeling of what went wrong, but I did not have strong arguments to support that opinion. Hofstadter, however, provides a very nice explanation for that on pages 90 and 91:

… Therefore, when someone gives a definition for a common word in the hopes that we will abide by that definition, it is a foregone conclusion that we will not do so, but will instead be guided, largely unconsciously, by what our minds find in their associative stories…

In short, redefining a common phrase is not going to work. Whether we like it or not, our understanding of a common concept gets in the way of applying it in a different context. “Gödel, Escher, Bach” offers some very interesting examples how attempting to impose definitions of common phrases and words was a very hard thing to do throughout history, starting with that Euclid’s Elements and his attempt to specify what “point”, “straight line” and “circle” mean.

On page 94, Hofstadter explains another interesting idea:

…The symbols automatically pick up passive meanings in accordance with the theorems they occur in…

So regardless of the actual name used for something, our mind gives it a passive meaning depending on the way in which it is used and cooperates with other concepts. If a name given to some concept does not match the way it is being used, we will effectively attach a different name and a meaning to it. The way things are used dictates how we perceive them, regardless of the names that were enforced for those things.

Armed with this new insight, here are some ideas that I will definitely try on my next project:

  • To name a concept, start from the way it will be used and try to find a intuitive match for that.
  • Avoid generic names such as “Controller”, “Manager” or “Content”. They already carry too much ambiguity.
  • For all common phrases from the business or technical jargon that have been selected for the ubiquitous language, double-check that there are no other related meanings that could cause confusion.