Which language to write code and comments in can sometimes come up as a question in countries where English isn't the native language.
There's both good and bad things with doing this, and I thought I'd list a few thoughts about it.
The bad things about writing code and comments in your own language is:
- People that don't speak the language can't easily work with the system. This involves both professionals moving to a foreign country and concerning outsourcing.
- There will always be mix of languages involved. Any external libraries/frameworks/components will use a different language.
- Any characters not present in the English language will have to be converted somehow. If there's no match, this can lead to various translations.
The good things about using your own language is:
- You might have an easier time with your ubiquitous language. Speaking in a mixture of languages or trying to translate could lead to misunderstandings and loss of important distinctions.
- You might use less time finding the correct words.
Did I forget anything obvious? What do you think?
2 comments:
My take on this is that we are always working in at least two domains. Of course there is the domain that the application is working in, the customer’s domain. But we must not forget that we are also working in the technical domain, the developer's domain.
If you're creating an application for banking, the domain is banking where typical concepts are account, money, loans and so forth. Say you're working with a Norwegian bank, and they use Norwegian terms for their banking domain. In this case their domain language is in Norwegian, and the ubiquitous language should also be in Norwegian, or else we're distancing us from the customer’s domain language. I've been on projects where the norwegian domain language were translated into english in the code, causing quite a lot of confusion. It made the developers and domain experts understanding even less of what the other were talking about. So, I think that the domain language should be in the native language.
But as I said, there is another domain here. It's is the technical domain. As developers we're used to talk of queues, stacks, patterns, lists and so forth. In addition we prefix our methods with is, has, get, set etc. Our technical domain is always in English. Translating this into a native language, like Norwegian, is weird. I've worked on a big project that did this, and although you get used to it, there where room for misunderstandings, and it just didn't feel all right.
So I would actually argue that you keep the customers domain in the language they are used to, and then keep the technical domain in English. It might feel a bit weird to use different languages, but I think it leaves less room for misunderstandings, keeping the domain languages as close to the domains as possible.
Interesting thoughts!
Another thought comes to mind: What do you do with applications that fulfills needs for several countries? Say you have an application which is going to be build for two countries, say Norway and Sweden. Perhaps you start off with Norway, get V1 up, and then you need to improve the application to suit the needs of Sweden. Say it's banking or insurance for instance. The domain is fairly similar, but there will certainly be modifications to both the domain and the application to suit different business needs, different legal requirements, existing services, etc.
To do that you'll need to communicate with users and domain experts from the other country. Do you translate from Norwegian to Swedish on a per communication basis when communicating then? Since the language difference between Norway and Sweden isn't too big, hopefully subtle differences won't cause to much problems. And if that works out nicely, what if UK is next?
That was a lot of questions, and it is as with anything else in our industry: it depends. I like your point, and I'll certainly consider it. I guess YAGNI can be used on variations of the example above, but it certainly is a thought to be aware of.
Post a Comment