views:

18

answers:

3

At my current job, it goes without question that if a new version of a technology that we use in our project is released, we upgrade it ASAP. At my previous job, that was not the case... we had to convince management that it was necessary. As such, we often had to do without features that could have been helpful and continue living with bugs that had long ago been fixed. At times, it was even hard to get support for the old versions we were using. I don't really see that point of view, especially after experiencing the opposite approach. Are there really 2 sides to this question?

+1  A: 

Of the two approaches, I absolutely would prefer the one where you are now. Having applications falling behind can be painful for many reasons, some of which you noted.

The only caveats would be centered around time, really; it would usually take some non-trivial amount of time to update something for new frameworks/dependencies. It's nice when frameworks maintain backward-compatibility, but that does not always happen.

Breaking changes are usually obvious, and usually (we hope) exist for some very good reasons. More troublesome are the silent changes that do not prevent building, but cause subtle bugs; like a library function with the same signature, but which has slightly different behavior or return results.

But if an application is meant to be supported long-term, keeping it up-to-date is really a must, IMO.

Andrew Barber
+1  A: 

There is a grey area that lies somewhere in the middle.

Your old place lived by a "don't rock the boat" approach. Yes the stuff might not be up to date but they knew what it could do (and maybe couldn't) and how to handle it. If theres an issue you hopefully know its not the kit as its been around the block (or you've been around the block find out all the bugs in it and how to handle them and keep your kit up and running).

Your new place puts all their faith in the fact that the newer kit must be better and can't possibly have been released without lots of checks and balances. Yes there might be some quirks but knowing some of those old bugs are no more (well the release docs say its fixed anyway) is worth the time spend finding new bugs in the latest release.

Its a fine line to tread and depends very much on what the tech is used for and how mission critical it is.

Pete Duncanson
A: 

Yes, there certainly are two sides to this question. I'll weigh in on the side of not upgrading whenever a new version is released ...

  • If it ain't broke don't fix it. If your system is working then any change is a risk, not all risks are worth taking.
  • If you upgrade every time a new release of any component pops up you will find yourselves following other people's schedules.

Change management is vital discipline for robust and reliable systems.

High Performance Mark
Are you sure that upgrading is the only risk? Maybe not upgrading is also a risk?
JoelFan
@Joel not upgrade is also a risk but it's (more of) a known risk, whereas upgrading introduces more unknowns. It often comes down to how well you trust the publishers to not have buggy releases.
Davy8
@JoelFan: sure, not upgrading can be a risk too -- part of change management is weighing the risks of upgrading and of not upgrading.
High Performance Mark