A pathology I’ve noticed in many large organisations is inertia in failing to keep up with recent versions of development tools. It’s not uncommon to find .NET shops still using Visual Studio 2005 and .NET 2.0. Even 1.1 is not unknown.
The usual reasons for not upgrading are down to fear and/or incompatible 3rd parties.
Fear comes from the worry that newer versions of compilers and runtimes will introduce bugs into the software. This is especially prevalent when teams don’t have a robust testing and release pipeline set up. If you have a fragile and brittle codebase that’s hard to deploy and hard to test, you are naturally reluctant to do anything that might introduce instability. No matter what Microsoft might say about the ease of upgrading, they have a history of breaking things with new versions, so the safe bet is to do nothing.
But if fear of breaking your brittle and unstable software is the main reason you are reluctant to upgrade to the latest tools, there is far more wrong with your development process than simply being behind a few versions of Visual Studio.
Incompatible 3rd party libraries and frameworks are a more pernicious problem. Since the CLR version hasn’t changed between 2.0 and 3.5 there should not be any problems with mixing older tools. However, if you are building tools or frameworks for customers who refuse to upgrade then that’s a separate problem. But even then, you should be able keep backwards compatibility while moving forward.
But why is it so important to stay reasonably up to date? I think there three main reasons:
- Being left behind by newer tools and the .NET community in general.
- Missing out on newer features.
- Developers don’t like to use old tools.
Being left behind by newer tools and frameworks is probably the most serious problem. As your version of the .NET framework falls further and further behind, it’s harder to find tool vendors or open source projects that can provide compatible versions of their frameworks. An obvious example of this is the popularity of lambda expressions in the APIs of many modern tools. If you’re not using 3.5, you can’t use the tools.
A related problem is that the most readily available documentation usually refers to recent versions. The same goes for blogs, newsgroups and other sources of online help and documentation. Before long you find that every issue you search for leads to information that you can’t use.
Missing out on newer features is another potential source of lost opportunity. Development tools really do get better over time. WCF is a far superior technology to asmx web services; the MVC Framework is a much better way of developing websites than Web Forms; and LINQ is a much better way of writing queries over data structures than for loops and if statements. The list goes on and on.
Lastly it’s de-motivating to be stuck using old tools. All the best programmers want to work with the latest toys, and you do want the best, don’t you? Allowing your development tools to slip further and further behind makes it harder to recruit keen young coders and you risk your current team moving on for worry that their skills are getting legacy.
Some developers don’t like learning new stuff and will resist the adoption of new tools. You really don’t want to be employing such people. If your staff are the main reason you are still running with 1.1, you are in serious trouble.
So how hard is it to upgrade from 2.0 to 3.5?
There are three main parts to the .NET Framework: the Common Language Runtime (CLR), the Base Class Library (BCL) and the compilers. Understanding which has changed with which version makes it easier to predict any problems you might have.
The change from 1.1 to 2.0 was big. The CLR, BCL and compilers all changed. The flagship feature was generics. Migrating from 1.1 to 2.0 was a major upgrade which required some care and planning.
The change from 2.0 to 3.0 was the addition of three major new areas to the BCL: Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) and Windows Work Flow (WWF). Neither the CLR nor the compilers changed. Upgrading was straightforward. Many commentators complained that it didn’t really justify a point release number and should have been labelled as 2.5.
The change from 3.0 to 3.5 was more important. The CLR didn’t change, it’s still the same as version 2.0, but there were new compilers and language features and extensions to the BCL. The flagship new feature was Language Integrated Query (LINQ). Because the CLR didn’t change the upgrade should not be difficult. The new language features are extensions; version 2.0 code should still compile.
Visual Studio 2008 has a .NET 2.0 mode, so it’s possible to upgrade your development tools first and your software later. 2008 has been around for more than a year now so pretty much all the major add-in vendors (I’m looking at you Resharper) have caught up. There’s no reason not to make the change.
To sum up, unless you have a dependency from a client or supplier that means that you simply have to stay with .NET 2.0, it really makes sense to upgrade. The upgrade is pretty painless but provides many benefits. Even if you have to stick with the 2.0 compilers you can still use Visual Studio 2008 in .NET 2.0 mode.
Posts
6 comments:
Great post Mike, very clear and all salient points well made.
It's almost designed to send to annoying managers who don't embrace change eh!
Cheers
Great post, some good points there.
If there's one thing that large organizations are slower at than upgrading the version of .NET that they target, it's upgrading their SQL Servers!
Surely it's pathological to still be running SQL 2000...
nice how the first comment kind of makes it difficult to pass this on now. way to ruin it for everyone, neil!
JonR :)
And what do we do about our customers who are on Windows 2000?
One factor that huge companies are more slowly at than improving the edition of .NET that they focus on, it's improving their SQL Servers
Post a Comment