A post on the Domain-Driven Design mailing list got me to reflect on a recent project we did in the domain of accounting. This was a completely new and unknown domain for us as a team and it sure took us a while to grasp the different domain concepts. After some meetings with the (Dutch) clients and as soon as we had enough understanding of the domain, we started developing.
(On a side note: I couldn’t help but notice that our client was pretty inpatient whilst teaching us about accounting.)
As a company-department standard, we program all code in English since it feels the most natural given the fact that most (if not all) API’s we use are also written in English. However, we quickly faced the following problem: What are the English translations of the different domain concepts we just learned as part of this accounting application? As a result, I spent a fair amount Googling around to find dictionaries with accounting terms and finally wrote down a translation scheme for the domain objects.
Although I’m pretty sure we got the correct translations of the domain objects, it felt awkward at times to work with the API we were creating. In fact, it made developing quite a bit harder because we had to constantly translate terms when we were talking amongst developers and when we were talking with the domain experts/the client at iteration meetings.
On the other hand, mixing Dutch and English code is also pretty awkward and could make the code hard(er) to read. So I’m still kind of undecided about what option to choose. I guess it depends on how transparent the translations of the domain objects are and how easily they are interchangeable.
Does anyone have any experience with this? How are or would you be handling this situation? Do you prefer sticking to English with the added complexity of dealing with domain object translations or do you develop in the language of the domain experts?
Damn you tower.
Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
Christophe Herreman is a software developer living in Belgium. He's working on high-end Flex and AIR solutions at
February 20th, 2008 at 1:38 pm
Hello,
I work for a Dutch company called Rhinofly. Here we have the same policy when it comes to coding standards: everything in English. We indeed come across the same problems. We decided we would stick to english. If there are more words available in English for the dutch word, we select the best fitting and understandable word available. Translations indeed at times may be strange, but it has payed off for us. English words used for specific dutch objects become easier to work with over time and translation in a conversation becomes more natural.
Greetz Erik
February 21st, 2008 at 1:44 pm
“If there are more words available in English for the dutch word, we select the best fitting and understandable word available.”
since finance and accounting is a world-wide practice, wouldn’t the same concepts exist no matter what language?
were humans. we are essentially the same people. in this case following the same endevours. just because we use differnt sounds to describe things, does that make the things different?
http://www.mendosa.com/snow.html
so, what’s wrong with picking one language? it could be worse than picking that mess of a language called “English”, it could be … Esperanto …?
February 22nd, 2008 at 8:18 pm
Hey Christophe!
I think it’s a good idea to use English as the programming language of choice, simply because 98% of the tools and API’s we use are in English too.
Indeed it can be difficult some times to having to constantly be thinking in a language that is not your native speech, but I feel that mixing 2 languages and having to switch between them the whole time should be at least as fatiguing.
How about documenting your code in both English and Dutch? It’s perfectly possible to do, allows anyone who knows English to understand your code, and makes it easier for yourself to keep track of what you’re doing.
It’s how I do it, and it makes me feel happy