Nearly every industry has developed a special language that only people from that industry fully understand. Some of those words spread out to the world, like the automotive world enriched our language with terms like gearbox, ignition, combustion engine, and even body shop. The last term is apparently ambiguous when being looked outside of the domain. But as soon as the domain is specified, it becomes clear that we do not mean a beauty product boutique, not a software outsourcing company, but a place where car bodies are being repaired after accidents.

Of course, the automotive industry is not unique in this sense. Other industries have developed their terms, and their language might be much less known and more cryptic for outsiders.

One of the examples of such an industry is, of course, the software industry. When two programmers discuss implementation details of some reasonably complex systems, non-programmers around them don't understand much of this conversation and usually get bored. Lack of understanding always results in lack of interest as shown:

The software industry is in a sense unique because it tends to serve a variety of business problems within any other industry. Almost everything today requires or wishes some degree of automation and this means software. This also means that people from the business will come to their developers or external software companies and will try to express their problems using their language. When this language is not properly understood, problems arise.

Functional requirements, written by dedicated professionals, who are neither business people nor software developers, have been seen as the holy grail of successful software. Each time we reached an undesired outcome after the software has been delivered to an unhappy customer, we blame requirements. We say; next time we will write better requirements, more detailed specifications and explain what developers need to do down to every single small detail.

In addition to the points we were discussing in Chapter 1, Why Domain-Driven Design (section What went wrong with requirements), one additional aspect is worth mentioning here. It is the language. Not only requirements focus on the solution and hide problems, requirements also tend to translate business language to more technical language, which is seen as developer-friendly. In reality, this works more like a broken telephone. The more levels of translation are being added to the transmission line, the less relevant information reaches the received without being disturbed beyond recognition.

One more aspect of such translation is that it slows down the communication. If developers require more information from the business but are unable to understand what the business means when they speak, the involvement of translators becomes unavoidable. Usually, these are the same people that write requirements, but not always. I have heard enough examples when only people like enterprise architects are allowed to talk to customers, then they translate their understanding to business analysis, who then throw requirements over the wall to poor developers, which are then literally lost in translation.

That's is why understanding the business is significant for people who are working to create a good solution for real business problems. Being able to understand the business and communicate without a need for translations and translators not only shortens the communication time but also substantially improves the quality of such communication.

For example, London city bankers are notorious for hiring developers, who were already exposed to banking and ideally worked in the city before. They value their time and want to shorten the time spent on communication and discussions. Therefore, someone who has exposure to their language and shows a decent level of understanding of their business and their language is valued higher than someone else, who might be a better developer, but needs to be trained and get to know the language before really starting to work on real-life tasks.

Jargon terms are usually hard to grasp for outsiders since words that are being used are often every-day use words, but have entirely different meaning. Some examples from the aforementioned financial domain are:

• Call: Short for a call option, a demand for payment of lent or unpaid capital.
• Security: A certificate attesting credit, the ownership of stocks or bonds, or the right to property connected with tradable derivatives.
• Swap: An exchange of liabilities between two borrowers, either so that each acquires access to funds in a currency they need or so that a fixed interest rate is exchanged for a floating rate.

Learning the domain language is crucial to establish effective communication between domain experts and developers.