When To Upgrade (and when not to)

I have often found people divided on this matter.  Some people always want to be on the latest version, it doesn’t matter what it is, but if there’s a newer version out there, they want it.  The other extreme is people clinging on to their old version and wanting it to run forever.  So much so that if they are forced to upgrade because of the operating system, they would rather run the older operating system as well.  There are arguments for both cases but camp A will get stung eventually when a new software release is detrimental and they can’t go back to the old version.  Camp B will get stung when they can no longer get support for their version and they are forced to upgrade.

So which is the better option?

Version Numbering

It comes down to understanding version number.

Version numbering comes in 3 Parts, Major Minor and Revision. A forth can also exist that refers to the incremental build number.

So we have version 1.4.8 of an application and they release version 1.4.9.  What can you expect to have changed in that release?  Not a lot in all honesty.  The most likely thing is bug fixes which were deemed urgent enough to make a release for.  It is these updates that you should avoid unless you have experienced the bugs in question.

The next upgrade might be version 1.5.2 this is a minor release; there may be improvements in security or a new feature requested by a number of users.  Again, I would be reviewing what the differences are between the two versions before upgrading.  If I’m never going to make use of those new features, it probably isn’t worth taking the risk of updating the software.

The Major release is the biggest upgrade you’ll encounter.  This could be a major overhaul of how the code works and the number of features that are available.  Not all major releases will have features added.  Some may be taken away because the development team have found they are troublesome to maintain and test.  Or based on user feedback have decided not to keep that feature.  Other reasons behind this could be incompatible operating systems or other software on the market or there could be legal reasons behind it.  The UI may have been overhauled giving it a different look and feel.  Users of Word 2003 to 2007 will have noticed a huge difference in how the application looks and operates (does anyone actually like the ribbon functionally compared to the humble toolbar?)

Switching Vendors

So there are reasons why you would never want to upgrade your software provided it is working as it should.  But what’s the other type of software upgrade?  This is where vendor switching comes into play.

Say you have Crystal Reports 8.5; you’ve kept with this version because it allows you to compile the reports and distribute them as Executables, thus eliminating the need to install an expensive licensed piece of software to all of the machines that need to run then.  Version 9 or later doesn’t allow you to do this so you’ve avoided upgrading it. After all, it works and you’re happy with it.

Sooner or later Crystal Reports is going to look very outdated compared to other companies software.  The terminology used within it doesn’t match any other products of a similar nature and guess what, anyone else joining your company isn’t going to have been trained in that version of Crystal Reports or maybe hasn’t even heard of Crystal Reports because it is that old.

So at some point you’re going to have to upgrade to something or face an extortionate bill finding the last person on the planet willing to get out of bed to support the legacy application.  I for one hope to make a mint out of writing conversion packages to take a report from one system and convert it to whatever other product is on the market e.g. SSRS.

Its not my fault, the mechanic did it!

Whose fault is it anyway?

I recently had the misfortune of having to deal with a difficult "customer" but I was glad it happened because I've been waiting to use this analogy for ages.

The usual story with chaotic IT departments is that they get the blame for everything.  The customers lose faith in the IT departments ability to deliver or maintain and as a result whenever something doesn't work as intended the propensity is to blame IT.


The problem that was put to me was that if the system wasn't working, the stores couldn't process orders and do their work, and this creates a problem.  The regional manager wasn't getting that what he'd described was not our problem in anyway.  It was beyond our control and the users were actually part of the problem due to their lack of instruction, propagated by the lack of leadership in this area.  When the supervisor doesn't know how to do something, they can't teach their direct report staff how to do it either.  Enter the analogy.

The analogy

I asked him how he used to do things before the computer system was there.  A little bit of a struggle but in the end, he accepted there was always manual ways things could be done and a good old piece of paper and pen was always to hand.  I related this to his journey to work.

Before you had a car you walked to work, the invention of the Car made it much more convenient for you to get to work and cut down the commute time immensely.  You were happily commuting to work in your car for many weeks, you couldn't even remember how you got to work without it.  One day, the car breaks down and you get a quote from the mechanic saying it will take at least 3 days to fix.


So in the meantime what do you do?  If you don't go into work there will be consequences but who's fault is that?  Not the mechanics fault, you can't hold them responsible for you not being able to get to work.  You can shout at the mechanic in the hope they'll work faster but if they have got to order in parts and wait for them to be delivered that won't really help.  It's not the mechanics responsibility for you to get to work, the car is just a tool to aid you in doing the job.  If your car is unreliable, consider getting a new one (see my next blog When to upgrade and when not to).  The analogy can go deeper here about the similarities between vendor lockin and leasing deals on cars but that's not the idea of this blog.

Implementing SQL Emails in SQL 2000

Stop with the Polling

In lots of legacy systems there is a problem of polling.  A job or routine comes along on a regular basis and checks to see if there is some work to do.  When it finds something, it actions it and moves on thinking everything is great.  In even more disjointed systems, they will then have another polling job that should run as part of the other job, but for whatever reason decides to do its own polling to see if work should be done.

This creates a problem in many cases because Job A may come and poll again before Job B has had a chance to do its bit.  What if Job A is cleaning up after itself or overwrites what it did the first time and Job B hasn't had a chance to get what it needed to complete?  This is a common scenario for polling and one of the reasons it is bad in modern computer and why event driven processing is preferred.  Quite often this is solved by implementing a listening pattern but my problem didn't need to go that far.

Legacy Emails

One of the features of SQL Server 2008 is the ability to send out emails using the inbuilt stored procedures for handling mail.  This can be a very useful feature as it saves you having to have a mail client installed on the server and saves another failure point to check if emails aren't being sent.  My problem was the Jobs in question weren't on SQL 2008, they were on SQL 2000 which doesn't natively support this email functionality.  My initial thought was to write a client that would interface to the smtp server and I could call into this with xp_cmdshell.  I stopped myself short at this point because of code smell and realised this problem must have been solved before me.  We're in 2012 FFS!

Sure enough after some searching I was able to find the article that MS have written on this very matter
http://support.microsoft.com/kb/312839

Golden Hammer

The trouble is, now my work colleagues think this is great and have started flooding email addresses when jobs complete, fail, take too long etc.  I need to remember them that there's a time and place for everything and not all solutions can be managed with a simple email.  Plus if you're getting a lot in one day, surely a report on a daily basis would give a better indication of how big your problem is.  You may even want to keep an audit trail of when these things happen so you can get some meaningful stats in the longrun.