When to upgrade an existing program to new language features?

Question

Imagine you have a program written e.g. in Java 1.4 or C# 1.0. Of course this program doesn't use generics and other language features that were introduced with later versions.

Now some non-trivial changes have to be made. And of course, you already have a newer IDE/compiler so you could use Java 1.6 resp. C# 3.5 instead. Would you use this oppurtunity to upgrade to the latest language features, i.e. use generic containers and get rid of many casts, etc. Or would you leave it like it is, and use the new features only for new parts. Or even stay with the features of the version originaly used, to maintain a level of consistency?

Answer 1

It depends. Does it need to be compiled by old compilers? Do you have enough time/money to change everything?

Answer 2

My basic rule for code maintenance: If it ain't broke, don't fix it.

Answer 3

As far as possible, leave working code alone. It may seem like the code should all be using the latest programming secret sauce, but there is a lot to be said for tried and tested code.

I would only consider rewriting code that must be heavily modified in any case to add a new feature, and even then I would only change the programming metaphor if it will speed up the writing of the new feature.

Otherwise you will constantly be debugging code which was previously working, and using up energy that could have gone into improving the product.

Answer 4

It's just one specific form of refactoring, so all the advice on when and how to do that applies.

Answer 5

One consideration here is your present and future ability to attract and retain developers to perform maintenance and support on an application built with outdated technology. Many seasoned developers worked with those older versions of Java and C# when they were current, so it isn't that we have no experience with it. But if we spend, say, a year working in .Net 1.0, we will be forgetting what we now know about subsequent versions. And while we are spending that year working in old technology, all of our friends and competitors are honing their skills on the latest technology. We will never be able to make that year up.

In addition to falling behind, we will find it intensely frustrating not to be able to use the functionality in the later versions that we are now comfortable using.

So, younger developers will not have had experience in older technology (.Net 1.0 was released in January 2002). Older developers have been there and don't want to go back.

On the other hand, if you stay back in the older version, you will be comfortable with your skillset. You won't have to spend a lot of time learning about newer technologies. And perhaps best of all, you will have job security.

Answer 6

In theory, it's a simple balance between costs and benefits, so you should only do the rewrite if the benefits outweigh the costs.

The problem with that is that it's almost impossible to measure the real costs (not only of doing the work, but of not doing other things that might contribute more). Generally speaking, the benefits can't really be measured at all -- you can only guess at how much difficult something would be if you'd stayed with the old code.

That leaves us with little chance to do anything based on rational measurements. That leaves a simple rule of thumb: leave old code alone until your only choices are to rewrite it or abandon it completely.