One need a tool that support the product being created.

If the product being created does not change then there is usually little need to upgrade the tool (new color scheme in the IDE does not justify an upgrade).

To me it makes most sense that:
- product X in version A.* uses tool Y version Z
- product X in version B.* uses tool Y version Z+1
so that:
- products has a stable tool set
- upgrades of tool set is done with major upgrades of the product

Note that if developers are working on multiple projects, then they may need to have multiple versions of the same tool. It can create problems. But that is just how it has to be.

posted October 12, 2009

I usually like to keep my main development machine current with the latest and greatest, and keep a few virtual machines around for working on old versions (ex. VS 2003).

posted October 12, 2009

Labor is much more expensive than tools.

I do look to see if the new version is helpful turning out accurate code faster but it usually is. I also consider if the upgrade is timely in the development cycle but the decision has to do with lower labor cost overall.

posted October 12, 2009

With over 40 teams to support, and using quite highly integrated software toolsets, upgrade is a nightmare. If every version were compatible with every other version of the tools it integrates with, or at least compatible with the older versions including the current, then upgrade of tools would be a lot simpler. As it is, we often wait until versions go definitively out of support before making changes - "You change now - either to a new version or to no version".

Given the choice, I'd go for tools that don't directly integrate, but go via an IDE and use 'standard' ways of interchanging information so each team can make their decision independently, of the versions we import onto site. Licensing costs are a major factor in our decisions. I am strongly inclined to go for tools with cheaper or no licensing costs, as there are almost always tools that give as much benefit and cause less hassle, built for developers by developers rather than built for tools vendors by marketing people.

Yes, I think the environment makes a big difference. One subset of teams get to choose and migrate to their own choice of open source tools; they are the most advanced and the least hassle. The main concerns for the central tools team are that any licensing constraints are taken into consideration and that the tool is not a security risk (trojan or the like).

posted October 13, 2009

As a general rule, I only upgrade when compelled to either by a new feature that will improve my productivity or the necessity of matching versions for a project. For example, I still use Photoshop 6 because the files are compatible with newer versions. While I know there are new features is later releases, they have not been valuable enough to get over the menu changes that have been made. On the other hand, I generally upgrade Eclipse every year or two because some new feature makes it worth it to find compatible versions of all my plug-ins.

The exception is the highly stable upgrades. The only one that comes to mind at the moment is Poseidon. In the case of Poseidon, there are no plug-ins and the output is always backwards compatible, so no worries.

posted October 13, 2009

Personally, I try to avoid "buying" development software. I look for freebies. For instance, I attended the Microsoft Launch event and received a free copy of Visual Studio 2008, SQL Server 2008, and Windows Server 2008. I attended a MSDN (MicroSoft Developer Network) road show, and won as a door prize a free copy Microsoft Office 2007 Ultimate. However, I am currently running Windows Server 2003 at home for self-study on SharePoint.

At work I use Visual Studio 2008 (my decision) and Visual Studio 6 for enhancements to existing products. I would expect to upgrade to Visual Studio 2010.

The reason to upgrade regularly is that employers are asking you to have experience with the latest tools and software, so it makes sense to upgrade your development software and skills whenever possible.

posted October 13, 2009

Around these parts, no we don't. Each upgrade to our toolchain poses a risk, so we only upgrade to fix major showstopper bugs. If we had better end-to-end test coverage (working on it), this wouldn't pose so much of a risk, and we would upgrade more frequently, but it is always difficult to retrofit a project with end-to-end tests and ensure you are testing all of the functionality in use in the field.

We are still on VC6 for the primary project I work on. I've spent some time playing with upgrading to VS2005, but have found there are some problems with upgrading - we will have to change our build process and work through dozens of minor incompatibilities in hundreds of places across our sources - not many of these are places which are currently under test.

For projects at home, I let my Linux distro determine what version of the toolchain I get, I make sure I have 100% coverage. It helps that version upgrades in the Linux world occur in smaller steps.

posted October 13, 2009

Hi Mark,

Generally speaking when it comes to my development environment, I try to stay away from upgrade like the plague. My overall goal is total stability and predictability.

Unless I'm totally forced to upgrade I tend to put it off for as long as I can. Perhaps this is due to some latent cynicism ('1 bug fixed = 3 new bugs injected'.) Security patches excepted, in this scheme.

I'm a strong believer in the "if it's ain't broken, don't fix it" philosophy. Hence, I do skip releases -- if I can buy more time with the existing release then that's what I do.

When I do finally upgrade my dev environment (which *always* resided inside a VM): prior to upgrades I always take a complete snapshot of the VM and place it on external storage for sake keeping. At that point my entire dev environment is "expendable": When bad upgrades (or mistakes) occur, I simply pop the snapshot back into the VM, and I'm back on my feet in no time. (Code gets committed to SVN so restoring a snapshot doesn't clobber my dev efforts.)

I cannot compare and contrast different segments of the industry (e.g., corporate vs consulting) because I've always work in just a corporate environment. That said, I think I'd be using the same approach regardless, unless there was an overriding reason not to.

p.s, I'd be open to more frequent upgrades (and risk those 3 bugs injected for every bug fixed) if backing up the whole VM was significantly faster, since while the backup is running, no work can be done.

posted October 13, 2009

Hi Mark,

As a MAC user and probably the only one in answering this question. I heard that you should do the necessary updates but I don't always follow that rule. I am trying to be diligent in doing that now that I bought a new computer.

You are right, it does take time for a lap top that needs to be plugged in which is not always an option.

Best of luck doing all of your updates.

toni

posted October 15, 2009