Don't let software get too out of date!

Don't let software get too out of date!

Owning software sometimes seems like a constant treadmill of upgrades and paying out money all the time, but it’s very much a case of getting what you pay for.

Many businesses that I see are still using old versions of Microsoft Office, for example – 2003 is still kicking about, despite being now unsupported by service packs. This is a function of the old pricing model, of course, where you paid your £300 and owned the software outright. The temptation then being to sweat it for every penny, and keep it running as long as possible.

If it ain’t broke … don’t fix it

It’s perfectly understandable that businesses don’t want to lay out hundreds of pounds per user every year or two, just for the software to allow them to write the odd letter. I don’t suggest that you should always have the latest version of everything, and there is a distinct case for the “if it ain’t broke, don’t fix it” approach.

However, I have a couple of cases currently where it is “broke” …

One client has an old database system that they have been running for many years, but it has begun to become a little unstable – data has been lost once or twice, and it does some unpredictable things. We upgraded the code to the latest version and it now falls over occasionally because it is several generations out of date, and certain things have changed under the bonnet that mean that some of the code needs to change. You never know quite where these changes need to be made until it fails.

Less critically, but equally annoying, are the little inconsistencies that the old version shows when running in the new environment – forms that were pop-ups are now full-screen; the order in which the cursor moves between fields when you hit the Enter key has changed; fonts are slightly different, so data no longer fits some fields and you get a row of ###### displayed.

All of these things need tweaking, and taken en masse can present quite a chunk of work. Keeping the system up to date over the years would have spread the load somewhat, and reduced the pressure to rework a system that is now causing problems.

It is broke … and we can’t fix it!

Another client has an equally ancient database which is also failing regularly. In this case they have fallen victim to a developer who only gave them a compiled version of their system, and retained the source for himself, which I personally don’t consider the correct approach in cases like this where the client has paid for a bespoke development.

It wouldn’t be so bad if we were able to negotiate to obtain the source code from him, but we have been informed that it has been lost.

The situation now is that we have to rewrite the whole thing, and time is of the essence, as the stability of the running version is not good.  This is problematic for the business and, frankly, for me too, as I need to try and shoehorn the work into my schedule in order to dig the client out of the ordure as soon as possible!

The moral of the story …

… is not to be silly and spend money hand over fist by upgrading to the latest version of stuff as soon as it becomes available, but be aware of the systems that are really important (or critical) to your business, and ensure that you review them on an annual basis, asking the following questions:

How far out of date are you?  If more than one or two versions of MS Office, for example, you should be thinking about your situation – it’s dodgy to be using anything older than Office 2010 now, in my view.

How stable is the system?  Do you keep a log of failures or problems?  Do you have support for the system if it should fail, or is it a matter of ringing someone like me up to come and help?

Are you in touch with (and have a workable relationship with) the developer, if you have a bespoke system.  Will they support it?  If not, do you have the source code, so another developer is able to pick it up?

Is the data in your system secure?  Not only does this mean that the system runs without falling over, but that it is backed up.  Critically, you also need to be sure that the backup is workable – you should test restoring data from it on a quarterly basis at least – more frequently for more critical systems.

Should it all collapse about your ears, all is not necessarily lost – many companies will suggest that you replace it with something brand new, which will involve a lot of work (and money) and may mean that you can’t use your old data – you may end up having to set a lot of things up again.

The alternative first step might be to approach some mug like me, who has a fair bit of experience in salvaging these situations – I will be able to give you an honest appraisal of your chances.  I won’t try and flog you a rewrite, if a rewrite is unnecessary.  As we have seen above, sometimes it is, but often it’s not – systems built in MS Office, particularly Access, can usually be recovered and upgraded as long as you have the file versions that contain the code.

Compiled files (usually with the extension .mde or .accde) are more difficult – the code isn’t in them, as they are compiled versions so unless you have the equivalent .mdb or .accdb file you are, I am afraid, hosed.  They can’t be reverse engineered beyond the ability to edit forms and create new macros – the source code for any Visual Basic modules cannot be extracted as it doesn’t exist in the compiled file.

Be careful out there!

Leave a reply

Your email address will not be published. Required fields are marked *