As time passes, however, you'll find that more and more of the initial reasons for the language choice will disappear. Perhaps the language expert left five years ago and you have created a new framework that better matches your needs. Eventually, you will have to find out whether the language you are using is still the best one for your needs. Looking at it 15 years later, should your website still be written in C?

You don't have to change a programming languages in one go; different systems can handle different parts of a web application, for example. It's also quite likely that there are bridging libraries that allow you to call from one language to another. The boundaries between some languages can also be blurred when you consider things such as Jython and Clojure.

Making the decision to change programming languages will never be an easy one. You must answer some hard questions: Will the effort of retraining be worth in the advantages in productivity? Are there enough trained developers with the new skills you require in your area?

One problem to watch out for is the creation of a large chunk of legacy code that nobody quite understands anymore. As staff members come and go, less people will remember the old code base and it will become hard to fix bugs. This knowledge loss may well have happened anyway; a change of programming language only draws a clear line in the sand showing where the difficulties start.

If you decide to rewrite some of your legacy code with the new programming language, you will have some new opportunities. You can use what you've learnt over the years to avoid some of the same design mistakes. And you can sometimes use the rewrite to provide new functionality. Unfortunately, you will also probably introduce new bugs. This is where a strong test suite can be very useful.