Which Language Do You Code In?

12 commentsWritten on July 18th, 2010 by
Categories: Code Quality

I got into an interesting discussion on twitter today on what language you use when coding. We weren't talking about programming languages, but the actual real world language that is used for class names, method names, variable names, comments, etc... My take on the matter is to just always do it in English. And for the record, i'm a native Dutch speaker and i work in Belgium. Our official languages are Dutch and French, not English.

A few years ago, i worked at a large financial institution in Belgium where we developed software for internal use in the main offices. The UI was pretty much always done in Dutch, but most of the time we wrote all of our code in English. There were a few projects where the developers had used Dutch in their code though. At first, this wasn't an issue and seemed to be more of a personal preference thing (though mixing within a project is just horrible). After a while, the company got involved in the outsourcing game and suddenly, they were sending a lot of the projects that were in maintenance to a group of Indian developers. It's hard enough to get developers who use a different language and are part of a different culture on the same page when working on software, but it's obviously even harder if the code they are supposed to read, maintain and extend is in a language they don't even know.

At my current job, we also have a branch in Hungary. We often mix teams so naturally, we all write our code in English. We not only write our code in English, but we also use English as our language in any kind of documentation. Now, we do have one customer who insists that the functional designs are all done in Dutch. Maintaining 2 sets of documents is something that we won't do, and since our development process requires developers to link our code to our functional designs, we'll never be able to use our Hungarian developers on the projects that we do for this customer. To me, that is a huge downside to having to write the documents in Dutch. And it's the exact same problem we'd have if we would write our code in Dutch.

Both those examples should tell you why i'm so much in favor of just writing code in English all the time. Generally speaking, if you pick a non-English language to code in, you are limiting the pool of possible future developers to those developers who know the language you've chosen. It's that simple. The more people who know the language, the bigger the pool of future developers. And when it comes to languages that aren't used by a lot of people... well, that's a pretty big restriction on your future options.

Another downside to using non-English in your code, is that you're effectively already mixing multiple languages in the code base. Your programming language already is in English, and using non-English in your code leads to something that just sounds (or reads, i guess) wrong.

The biggest problem that people bring up with always using English, is that you obviously need to translate business concepts. Especially for people who are doing DDD and who want to leverage the Ubiquitous Language, this isn't always an easy decision to make. For one, your domain experts might not be willing to take on the translation burden. If they are unwilling to do so, you can still use a translated version of the Ubiquitous Language but then the entire team (except for the domain experts) has to deal with that burden on a daily basis.

Now, i'm not sure if that's really that big of a problem. For starters, English terms are becoming more pervasive in 'business language' every day. I'm not saying that everyone is already using English for their business concepts/terms, but i would argue that it is increasing, that it's only going to increase more and more and most importantly, that more and more business people don't really have a problem with using English terms anymore.

And lets not forget that the percentage of teams that is truly doing DDD and leveraging the Ubiquitous Language is probably still small. After all, most true DDD experts will say that DDD is only a good idea for 10% of all projects ;) , so i can't help but wonder how big of an issue the translation burden really is.

Thoughts?

  • http://www.geekswithblogs.com/alternativedotnet Michel Grootjans

    I usually try to have this question answered during project kick-off meetings with the customer. In our small country (Belgium), any project that’s large enough is usually at least bi-lingual. The language of choice is then by default English.

    Of course there are exceptions. I have been on a project were we decided to use the Dutch business speak in our code. We came up with pieces of code looking like this:

    if (zorbehoevende.HeeftRechtOpVergoeding())
    GenereerBetalingVoor(zorgbehoevende)

    Maybe this code makes you wince, but after a while it felt suite natural to us. The main advantage is that our small team was talking daily with the customer, and we were continuously referring to the same concepts with the same words (ubiquitous language).

    This is only an example of a very specific case where using the customer’s language was successful, but it illustrates my point of view that you just can’t have one blanket statement about choice of language in your code.

  • Thomas Eyde

    I have, until a few years ago, always insisted on coding in English for the reasons that the major resources are in English, and the mixture of English keywords with non-English names looks very awkward.

    Now, two incidents made me change my mind:

    One customer demanded the code in Norwegian and after a few days it felt natural. I discovered then that my reasons were more like preferences. This particular customer did not want to alienate their domain experts by the translation to English. I have also been told that the translation were not easy to do, anyway. The domain in question was insurance.

    In another project we made the choice internally to code everything in English, as the customer would never see the code anyway. I was the last one to leave this project and have regretted this decision. The project was challenging enough on its own, so we really didn’t need the additional burden of doing the mental translation. And there were too many concepts we never got quiet right, anyway.

    The one thing I probably never will be comfortable with, is a mixture of languages. The language and the .NET framework are in English, and however strange we will find the mix of English and non-English names, I think the mix within the names are nothing but idiotic. By that I mean I can’t understand why anyone think it’s ok to name something like GetKunde() and LoadKunde(). (Kunde == Customer).

  • Diego Mijelshon

    I couldn’t agree more, and I wrote in the same general direction in Stackoverflow

  • http://weblogs.asp.net/bleroy Bertrand Le Roy

    In my experience, there are very few serious projects that in the course of their lifetime won’t be handled by multiple teams, either sequentially or simultaneously. In today’s world, there is a very good chance that these teams will live in different countries.
    English is the closest we have to a lingua franca, so it’s English, always, from the beginning of the project, because you never know.

  • Peter

    It all depends on (the size of) the country.
    For me English is the logic choice, but I’ve noticed that when you’re in France (or Italy or Spain) it’s not.
    The French certainly feel that French is the lingua franca.

  • Peter

    Forgot to mention, you notice it in small things, we’re all using the English version of Visual Studio, we’re not even concidering installing a Dutch version (if that exists) but the French use a French version of VS

  • Lars-Erik Roald

    Keep up the good work! This is my favourite blog !

  • Mario

    If you are trying to do Domain driven design in a good way, it’s probably easier to stick to the language that is used in the business, since, as mentioned in an earlier comment, the mental translation is smaller. Ofcourse this depends on the domain. For example; complex case handling in the public sector or in insurance would be much harder since it is much more subjective to national particularities in nomenclature and legal jargon. Thus translating the domain to another language would require a lot of work, and things could get lost in translation. On the other hand, developing an integration solution between a customer’s COTS CRM and ERP systems would should probably be done in English.

  • Endless, Nameless

    While I don’t actually have any say over the development process I personally prefer code and documentation written in English. In a previous life a company I worked for had subcontracted an offshore software development company to write some custom enterprise web applications. Frankly put, the code was dreck and the apps as reliable as a schoolkid with ADHD after a triple espresso. We tried to fix the code but couldn’t because we couldn’t understand any of it (it wasn’t in English). The software development company then renegotiated the contract and cranked up their rates for maintaining the code because they knew they had us over a barrel. I’m not saying that all offshore software companies are like that but a few are, and they can make or break you if you’re not careful.

  • Luc

    Our official languages are Dutch and French, not English.

    Don’t forget our German speaking compatriots :-)
    German is also an offical language in Belgium.

  • Adam

    You guys in Belgium are still in a good spot to code in English, basically everyone has the language knowledge to do so. Over here in Hungary we have quite a lot of people who have terrible English knowledge or none at all, even among developers.
    However I still support the idea, mostly because I hate mixing languages and the APIs are always in English.
    I was terribly annoyed though when excel had all the function names translated, it was impossible to use. That was the only exception I came across so far.

  • Luc

    I read this post right after reading “Is That How You Talk To People?”
    In a discussion about what language to use, I once defended Dutch. One developer was writing such terrible English comments and method names, very painful.
    The main two things to think about are, in my opinion:
    How big is the chance that non-Dutch-developers will get involved? (In the case I’m refering to, that chance was 0%.)
    How well are we able to write and understand English? Are we only going to see trivial comments in the code, or are we comfortable explaining complex things in English.
    In the end, if we would ever need to translate code, that wouldn’t take that much time. It wouldn’t be pleasant, but the cost wouldn’t be that bad.