Should developers fear updates to their workstation software / development stack?

Question

As I have discovered, many developers avoid any updating (automatic or manual), because they fear it might do changes to their machine they don't understand, and the software they are developing might fail at some point for reasons they don't know.

strategy A.) LEAVE THE SYSTEM AS IT IS, FOR AS LONG AS POSSIBLE.

I personally like to have my system as "up to date" as possible (OS and app's), because generally I feel to have less trouble working this way.

strategy B.) ALWAYS UP TO DATE

What type of developer are you ? And why ?

Answer 1

B. Definitely.

If you're developing for a platform with uncertain update pedigrees (e.g. The Real World) then virtual machines are an important weapon, but it pays to be as up to date as possible when you release.

It's so much easier to tell your users "just run the update" than to try and guess what patch history they might have that's causing the problem (or at least to be able to rule it out).

If you're developing for a purely internal audience then you've really only got one question:

• is there an update schedule for the company?
  • yes: then you need to ensure your software runs both on Production and on anything that's coming up
  • no: probably best to fix that.

Answer 2

No.

This is why God invented virtual machines.

Sort of a bummer if you're an OS X programmer, though, due to the hardware based copy protection in the OS (you must be running on Apple blessed hardware).

Answer 3

Keep the operating system as up-to-date as possible, preferably having a sys admin test patches before releasing them to the rest of the company.

Apply dev environment service packs reasonably quickly, but check on a VM first so you can see whether the build still works, and then give that build to QA for smoke testing before upgrading the dev machines.

Change dev environment (and/or platform, e.g. upgrading from Java 5 to Java 6) when you can see a real benefit, but allow it as an explicit task with budgeted time. Ideally, budget project time to get developers up to speed as well so they can make the most of it. Don't do this any time near a release.