The pennywise perils of clinging to ancient tech

As we all know, IT is not a priority for many execs. As the thinking goes, why spend money when the current technology is working fine — if it ain’t broke, don’t fix it, right? But a small company can ride this mentality [1] to an extreme.


A few years ago, I did some consulting work for a customer who put IT at the bottom of the list [2]. This was a small company with no IT staff; instead, one of the employees knew a fair amount of computing and stepped in when needed. The owner saw no reason to make upgrades. His policy was to spend the bare minimum on repairs and to work the hardware and software until they broke.


[ More from InfoWorld about the IT profession: Why admins should know how to code [3]. | Follow InfoWorld’s Off the Record on Twitter [4] for tech’s war stories, career takes, and off-the-wall news. | Subscribe to the Off the Record newsletter [5] for your weekly dose of workplace shenanigans. ]


I understand making the most of your assets, especially in a bad economy, but sometimes you need to invest in IT to avoid spending even more later. As a contractor, I didn’t like to intrude, but I mentioned to the owner the benefits of up-to-date technology. He insisted nothing needed to be changed — everything was fine. He also cautioned me to fix only what was called for and nothing more because he wasn’t wasting good money on my shenanigans.


At the beginning, I was called in for hardware problems. This customer had Pentium III-based servers in production that still worked fairly well. I helped replace failed hard drives (and clear out dust). I also tracked down used units on eBay because it was getting harder and harder to find parallel SCSI hard drives.


In addition, I fixed a couple of hot-swappable, redundant power supplies. The server manufacturer no longer made them, and I wasn’t able to find any used ones online. I ended up ordering parts from my favorite online electronic parts store and then doing component-level repair to fix those power supplies.


I tried laying out the situation in practical terms to the owner, explaining how one of the dangers in having such old hardware is that it becomes harder and harder to find replacement parts [7]. Even for component-level repair, it gets to a point where the labor cost for the repair is more than what the old hardware is worth. Furthermore, technology changes — CPUs have moved from 32-bit to 64-bit, for example. He waved me away, saying again it worked fine and there was no need to upgrade.


It was the same scenario with the company’s legacy software and custom applications. One day the customer called to see if I could help with a database problem. When I got there, I learned it was a Microsoft Access database linked to the CRM. The person having the problem said things were working fine until he got a new computer — a replacement when his old one finally quit. I allowed myself to think there was some small progress on the hardware side.


The database problem was most likely caused by a conflict with using current and very old software together. Given that this was a custom Access application, I asked if there was any documentation on it.


The user showed me an old worksheet about how to use the application, but nothing about the program itself. Nobody else knew of any, either, but one person offered a short history of the application, which had been created more than a decade ago by a former employee. They didn’t think any documentation aside from the how-to cheat sheet had ever been created.


I took a look at the Visual Basic code but couldn’t find any comments in it. Rather than go over all the code, I decided to start with the debug code and try to trace the cause of the issue.


I located the problem after a couple of hours. The Access application was “hard coded” to save a database to the root of the C: drive on the user’s computer. This file was then imported to the CRM via Access. This Access application was written back in the Win95 or Win98 days, so saving it to the root of the C: drive was no problem.


However, because the user had a new computer running Windows 7, the operating system prevented Access from saving to the root of the drive. I changed the Visual Basic code to have it save to the server where the CRM was running, and things worked fine after that.


After making the change I inserted comments in the code to give some basic documentation for the next unlucky person called to troubleshoot. And on my invoice, I also suggested they upddate their software more regularly. Hey, we can only try.


Do you have a tech story to share? Send it to [8]. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “The pennywise perils of clinging to ancient tech [9],” was originally published at [10]. Read more crazy-but-true stories in the anonymous Off the Record blog [11] at For the latest business technology news, follow on Twitter

Comments are closed.