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

OS: Up to Date (though I am not fanatical about it).

Small Applications: Not so much. I am wary of updates and will not upgrade unless there is some added value in it for me.

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

Once bitten, twice shy.

Answer 4

Do an update, but not during a critical period in the development cycle. Use an OS distribution known to be as stable as possible, and known to be conservative in how often they release updates.

Force your developers to test their code whenever they are about to do a check in. Make sure all tests pass before they do an upgrade. This ensures they have some idea about what is breaking.

Answer 5

A good example of this happened the other day at my work. The IT team rolled out an update to our development server which seemed harmless at first. The machine had an unattended login which had to stay logged in 24/7. The update for Windows (I'd have to pull out the KB) actually automatically logs out that type of user. The applications we run on the server require attended logins in order to run (yes, silly I know, but that's another story). Suddenly our systems started going haywire and complaints rolled in that some of the software systems being used weren't working.

We tracked down the problem and logged the admin user back in, but it wasn't until about three logouts afterwards caused by Windows that we really realised what was going on. Fortunately not much damage was done, but it did mean some people had to work overtime.

Updates should be checked for what kind of environmental effects they may have on your OS before being rolled out, and even then they should be tested.

Answer 6

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.

Answer 7

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 8

It hardly ever happens that the target machine for the software that you are writing is the same as your development machine. Therefore it doesn't make much sense to not update and to keep the machine all static.

Now, the target machine.. that's a different story. There I don't want any changes as long as they are not absolutely necessary.

Answer 9

B, for security reasons.

However how much you should care about that breaking things in your app very much depends on the type of development you are doing. The usual case is almost like a cross compile for a different target, as hardly any user machines are configured like dev machines are.

If it's a web application, your 'platform' is the browser(s) and whatever you use server side. For me that is ruby, rails, and plugins plus apache/mysql etc. Client side, I have no control over. Server side, I want to apply at least security patches (aside: plea to server side developers, please release security patches on a different cycle to functionality changes!).. But OS updates usually have little effect on the dev server stack I'm using, and in any case my deployment environment uses a different OS (I develop on OSX and Ubuntu and deploy on Debian and Solaris).

If it's a desktop application, then it depends how tightly integrated you are with your platform and whether you have control over it in the target environment. As I generally use Java, I see that as the platform not the OS, though it does need testing on different OS flavors and Java versions. If some patch to the OS breaks Java, then that's a separate issue.

If you are very tightly coupled to the OS, then update dependencies are very difficult to test for and is almost impossible without some heavy use of virtual machines plus snapshots etc. Also if you're that fragile with respect to OS changes your app will likely fail if your target machine has a different software load or different configuration anyway - again very difficult to test for.

Answer 10

There are a number of things to look at (I'm writing from linux/unix experience, but things should apply to other operating systems as well):

• Be aware of broken updates. Broken updates happen and it is prudent to let others suffer the breakage. Be especially aware of core components such as the c library (including OS interfaces typically included), linker, compiler, etc.
• Updating component libraries for your product should be done warily (or on a test system / vm first). Highly used libraries such as the C library are normally ok, but lesser used ones may contain API breaks or semantic changes in the API.
• Write your software to be tolerant of its environment:
  • Preferably use various differently configured systems to write
  • Write without assuming attributes of the environment
  • Update the system when needed, if something breaks get to the root cause and eliminate that.
  • Be especially wary of complicated system dependent build systems (they require much more maintenance than simpler (or automated) ones) besides the costs of rigidity.

I'm aware that unix like systems have more of a tradition in being independent than windows systems. That doesn't change the engineering soundness of OS assumption independence. So my advise is to update rather soon after a new update is available (not normally first day), but to make sure that it can easily be rolled back if things really break. If the project breaks, most developers would roll back, where a small team works on fixing it.

Answer 11

There is the old saying. "Never change a running system". I guess the horror stories about miserable updates are legion. I just can tell from my experience. If you base you software on "well-hung" up components the likeliness to break them is much lesser than things under a rapid change pace. Some example: Our IDE is based on the Win API and runs nearly unchanged since Windows 3.1 (where it was developed), we added a few nicecities over the years so I bet the package needs at least Windows 2000 to run. But I can assure you it survivec many OS updates from XP over Windwos NT, Windows 2000, Windows 2003, Windows XP, Windows 2003-64 and the "oh-so-shiny" Vista.

On the other hand I could not keep up-to-date with the gtk based port of it on Linux. The API changes are extreme. So this is what I hate the most about the open-source proponents, you are forced to redo your work over and over again just to stay actual.

Another example which has took me at least a good week of work wan update of a very small rails application from Version 1.1.6 to 2.2. (and that in just two years). I feared it would be worst, but was somewhat positivly suprised.

Regards