How Old <I>Is</i> That Software?


If you are using really old apps, you are not as alone as you think


I had an opportunity to visit an old friend of mine who is an IT manager at a midsize company recently. My friend has worked at the same shop for over a decade, and has seen products come and go and his data center transformed from using a small IBM mainframe and token ring to running Netware and Ethernet. My visit, though, was marred by a crisis: one of his users couldn't get access rights to her shared applications (most notably, Groupwise e-mail) when she logged in.

Now, I am not writing this column to ask for suggestions; subsequently, my pal fixed his problem and his user is no longer in distress. But it got me thinking about how companies upgrade their applications and how old in general their software versions are, compared to our fairy-tale lives here in journalist-land where we have the latest and greatest of everything. Truth be told, I still run Windows NT in my lab, just to give me some perspective. (And I keep all those ancient Windows CDs around just in case I have to test something out. I think I even have a couple of OS/2 CDs around.) But that is a test lab, my friend is dealing with real life.

You see, my friend is running on ancient gear: Netware 4.11, Groupwise 5, Zenworks 1.something, and that's just the Novell portion of his program. Most of his desktops are still at Windows 98, too. He knows he is behind the times. It isn't because he doesn't want to upgrade: It's a small IT shop and they don't have the time to deal with it. They can't really upgrade their Netware servers because they have production applications that run on the older versions, you know, those older versions that still make use of IPX, a protocol that Novell has moved away from. Their clients are all a mishmash and need to be refreshed, but they figured they would wait until they could roll out a new version of Windows. Plus, to make matters worse, there was a period of about a year when they didn't have anyone who really knew Novell on staff, and that was after spending tons of dough on a consultant who couldn't seem to get anything done. On top of this, the firm has a bunch of workaholics that don't want the IT staff to take down the network over the weekend, because they are working over the weekend. Does this sound like your shop?

This isn't a new problem, by any means. Back in the day when I worked for Megalithic Insurance in downtown Los Angeles, we had mainframe Cobol applications that were 20 or 25 years old. Actually, none of us knew their exact age because they all pre-dated the IT staff that maintained them. The code was actually commented with warnings about "Don't touch these next N lines because we don't know what this subroutine does!" Kinda scary.

So, I thought, let's see if this really is typical among you, our loyal readers. I ask you to take a moment from your day and send in the details of your Oldest Working Software.

Heck, let's make it a contest. No purchase necessary to win. Offer void in Oklahoma. Only readers of this site can apply, and you can have multiple entries if you are a real glutton for punishment. Tell me the details, why you can't or won't upgrade, and approximately how many desktops or servers are running this aging code. It must be a commercial product, not something that you developed. All entries become my property, and if you don't want me to embarrass you or your company, then tell me so and I won't mention any names to protect the winners. The winner will receive $25. Entries judged on originality, actual age of application, widest deployment, and other criteria that I reserve the right to change at the last minute. We'll announce the winners next week. Happy reminiscing!