Is it possible for a small company to switch their development language?

25 September 2007, by: Development

Lately I’ve been looking at the erlang programming language and found it very much to my liking.

Even though I’m not sure it’s the right language for my company it made me think about the possibility of finding the ‘perfect’ language some day.

If that would happen, would it help us in any way?

Would it be possible to rewrite the entire application, which might have taken years to develop, with a small team?

After giving it some thought I came to the conclusion that unless you have a large enough workforce where you can let a significant amount of people work on rewriting the application while an other group keeps updating and maintaining the ‘old’ version, it’s not possible to switch.

An other point is that all the employees are probably specialized in the programming language, which is currently used.

So even if we assume they are all intelligent enough to learn the new language quickly , it will still take time before they know it as well as the one they were probably hired for and have been using for years.

I always wondered why some companies who are clearly using the wrong tool (for example php) for the job (for instance an application with millions of users spread over multiple servers) did not just switch but after thinking about it I understand it better, most companies just do not have the resources to do it.

The moral of the story is:

Think hard and long about what language to use when you still can, because switching later might be impossible.


           Daniel  Versteegh


4 comments to “Is it possible for a small company to switch their development language?”

  1. arjan says:

    It’s an interesting thought; rewriting a system from scratch in a ‘better’ language or with a better framework. The larger your code base is however, the less likely such a rewrite is to succeed. Even when the new technology is really vastly superior. 


    I remember sending you an article about this subject a few years ago, when we planned a major rewrite of M4N (for the outsiders; this never happened). It may be illustrative to post the link to this article again:


    Joel Spolsky wrote about this some 7 years ago and he’s still right.


    As you mention, with a large enough workforce a rewrite is sometimes an option though. Both Apple and Microsoft have been doing exactly that; a complete and total rewrite from scratch of both OS 9 and Windows 9x into resp. OS X and Windows NT. 

  2. Andrew McVeigh says:

    yes, rewriting is a huge risk.  the problems of the "big rewrite" are also related to the dangers of Second System Syndrome (Brooks) where the 2nd system is designed to solve all the problems of the 1st, but ends up becoming overengineered and never delivered.(however, sometimes (rarely), a rewrite makes sense.  i’ve seen it work to perfection in a tiny number of cases, but i don’t know the exact reasons why it worked…  suffice to say, don’t do it unless the benefits are overwhelming or reengineering is a vital necessity)note that having 2 teams; one working on the old, and one on the new never works in my experience.  the new people think they can do better than the old ones leading to arrogance and a lack of understanding of the complexities of the previous system.  plus, the old team gets jealous and justifiably resentful.  very bad karma.Andrew

  3. Dantelope says:

    If the primary reason for a rewrite is to use a "better" language or framework, then you have failed before you’ve even started.Companies do not fund such undertakings because they are in the business of making money, not provide an education for their developers in new languages.I find it humorous that people want to rewrite applications that are only a few years old.  I worked for an insurance company in 2002 that was using COBOL code with an initial release date of — brace yourself — 1965.  They are just now getting around to rewriting portions of it that no longer make sense, but I’ll tell you this as a businessman…Do a mental calculation of the real return on a rewrite.  Did you get the benefit out of the last release?  When will a rewrite pay the company back — and make sure to include the risk factor for project failure since a huge percentage of IT projects can be deemed failures (either not finished, didn’t meet requirements, went well over budget and time, or were outright rejected by actual users).Wanting to do a rewrite in a different language with a different framework is the sign of a good developer/architect.  Knowing when that makes sense is the sign of a good principal developer/architect.My $0.02.  May be worth less in your neck of the woods.Dante 

  4. Jon Harrop says:

    Our company made such a change about 3-4 years ago when we ditched C++ and moved onto functional languages.
    We initially just wanted to learn OCaml, having heard rave reviews from many different people. Our first project in OCaml was a simple rewrite of our main product (visualization software). After only 4 months we were not only proficient in the new language but had also done so much development that the rewrite was as functional as the original code base, four times shorter, five times faster and vastly easier to develop!
    So we made the decision to ditch the C++ code base (and object-oriented programming in general) and develop only the OCaml. Following the growth of OCaml and the recent introduction of F#, we are much more successful as a business now than we ever were then. Granted that luck played a big part (we were not expecting OCaml to take off as it did) but the ability to monopolize a smaller market rather than compete in a larger one turned out to be very lucrative for us. Indeed, I’m not sure we would have survived had we stuck with the old technology.

Type your comment below:

Time limit is exhausted. Please reload CAPTCHA.

css.php best counter