Wednesday, June 20, 2012

Should the team upgrade to the latest version?

I manage a couple of teams of .NET developers. Like everyone else we are under pressure and deadlines to push out the next feature and keep our products moving forward, feature rich and profitable. Nothing new here.




The usual arguments put forward to justify an upgrade to the latest version of a framework or tool are one or more of the following:
  • It has new features.
  • It fixes bugs
  • It runs faster
They are acceptable and reasonable reasons but in my opinion not the most important.
The most important reasons for me to keep us on the latest releases are for developer engagement, retention and recruitment.
As a developer I hate to hear about features that are available but I cannot use because I'm not on the latest release and I know that most other developers feel the same way. The latest feature or paradigm in the current RTM version of your framework might not be the best solution for your project but we don't want it to be excluded because we don't have access to it. We want to be able to actively exclude it because it's not right for us.
When recruiting new members onto your team it makes it easier to be able to say "we use .NET [latest version] with ASP.NET MVC [latest version] and jQuery [latest version]." There are obviously other factors involved but this (1) eliminates the fear that the tools might not be current and (2) keeps you open to almost all developers out there. i.e. those that don't want to regress to earlier versions of a framework. We might not be using any features that have been introduced in the latest versions (we are) but at least that option is open to us.
For engagement and retention it's important for the same reasons. Everyone's happy because we all have access to the latest.
I believe that early upgrade is important to reduce the pain and is ultimately more efficient. If the team is used to upgrading the frameworks and/or tools frequently then it will be familiar, less painful and easier to plan for. For example, we try and upgrade to the latest version of jQuery once a quarter. We do this because our QA team likes to do a full multi-browser regression once a quarter and an upgrade to a new version of jQuery requires this type of regression.
I rarely attempt an immediate upgrade when a new version is released. I like to let it bake for 4 to 12 weeks and read some of the upgrade comments and let the owners address any of the issues the early adopters have encountered. By then there are a few good instructional blogs out there on how to deal with unusual errors and edge case upgrades.
I usually isolate the upgrade to be done by one developer, have him or her extensively document the experience and put a hard time limit on the upgrade attempt. If possible we push the upgrade out as its own release and don't combine it with features and bug fixes.

No comments:

Post a Comment