How to bungle a software upgrade

Ten years ago, I was the IT manager at a successful software company whose main product was aimed at large insurance companies. It was a DOS app that read records from large data files, did a little processing, and passed the results to other apps downstream. It wasn’t particularly pretty, but it was accurate -- and it was fast! It worked in batch mode, processing thousands of records per minute, which was a critical feature, considering how many records our clients needed to manage each day.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

We were doing well with this app, which was pretty much the industry leader. So in a classic it-ain’t-broke-so-let’s-fix-it-anyway move, some of our managers and salespeople began complaining that it wasn’t written for Windows. They lamented the fact that we didn’t have a nice Windows GUI we could put on our sales brochures. If we didn’t rewrite for Windows, they insisted, our competitors would eat our lunch! And while they had our attention, these same people decided that the product would be even more appealing to our customers if it worked interactively, so users could process a single record at a time.

This seemed an odd request, because as far as I could remember, not one of our customers had ever tried to use the product in this manner. Come to think of it, our customers had never shown much interest in a Windows version either. I expressed my concern, but the boss was convinced that a Windows version of the software would be our ticket to world leadership.

Most of our in-house programmers had been laid off by this point, so the boss hired an expensive set of consulting software developers. In spite of my stated reservations, I was put in charge of managing these guys -- requirements, test plans, testing, daily builds, and so on.

When I costed out the notion of rewriting the application from scratch, the boss decided it would be way too time-consuming and expensive. The developers suggested creating a Windows front-end that would manipulate the old, reliable DOS application in the background. I considered this approach to be a serious kludge. Worse yet, it made the app a lot slower. And it was almost impossible to run it in high-speed batch mode. But it worked, and it was cheap. My boss loved it.

We worked on the code for six months; then the copywriters showed up. In order to create compelling sales materials, they insisted, we had to redesign the menus so they’d look good in the brochure. We were already over budget and over time, and some changes made the app harder to use. Still, the boss insisted.

We had worked closely with sales and upper management, and they loved the “new” Windows version. Unfortunately, we hadn’t shown it to any of our users. Apparently I was the only person in the company who was feeling nervous about this. Finally we prepared to take the app, the new brochures, and a large sales team to the biggest insurance convention of the year.

Proudly, we demonstrated our new baby to some of our largest customers. They liked the interface, they loved the brochures, but they all had the same two questions: “How can we get this to run faster?” and “How do we turn on batch mode?”

Our sales staff had no answers. But I had one: “Keep running the old version.” Of course, I didn’t think saying it out loud be a wise career move. So I kept it to myself.