Using new Language and Library Features

Now here’s an interesting question that came up in conversation recently:

While maintaining a system, should you make use of new language/framework features or not?

Of course, context is everything when faced with such a generic question, as the best answer may vary widely from one context to another.

In my situation, we’re looking at a moderately sized bespoke system that took a small team of developers most of a year to develop for the initial go-live. Initial development was on the .NET 3.5 platform, using the C# language. Going forward, ongoing support of the system will be largely the responsibility of one or two developers, but with other developers involved for skills transfer and knowledge sharing.

When this system is being maintained, should the developers make use of the latest features of the .NET framework, or should they restrict themselves to that subset of features already in use?

I’ve heard people arguing both sides of this - those arguing for the use of new framework features, and those arguing against the same. I used to belong firmly in the for camp, but now I’m not so sure.

Those who are in favour of using new framework and language features argue

• that you gain from the improved productivity and performance afforded by the new features;

• that you retain the interest and motivation of your developers;

Those who are against use of new framework and language feature argue

• that you need to retain consistency of your codebase in order to maximize its maintainability;

• that you shouldn’t increase the complexity of the application without good reason;

• that it is unreasonable to require every maintenance developer to be a guru who knows all the latest;

What do I think? I think all of these arguments have merit - and that, maybe, we need to make decisions on a case by case basis.

One aspect to consider is the rate of change - how much maintenance is taking place.

If you are making an isolated (rare) change to an otherwise stable system, then first priority has to be given to consistency. Any change you make is going to be the only one of its kind - any inconsistency is going to be a potential landmine laying in wait for future developers.

Ongoing maintenance is a different story. When the system is being actively developed and enhanced, any change in approach isn’t going to be isolated and unique, but the first of many. Consistency is not unimportant, but it is less important than the ongoing productivity of the developers working on the system.

It’s important to note that considering consistency less important is not the same as considering consistency unimportant. If you are going to make changes to a system that are not consistent with the way it’s been done to date, make sure your reasons are sound. Documenting them wouldn’t hurt either.