Evaluating new products requires technical skills, and a boss with two brain cells to rub together Many years ago I had a job working for “Acme Codeworks,” a small mainframe software vendor. One day my boss asked me to evaluate a backup app as a candidate for acquisition. I installed it, and the mainframe promptly crashed. Off to the computer room I went, where my colleagues and I spent several hours bringing the system back up. (This fact should provide an approximate date for this story; these days, if an OS crashes, it usually restarts itself while you’re waiting for the elevator.)I tried starting the product one more time, and the system crashed again. Eventually I got a patch from the vendor that allowed the app to run. But it was a relatively unimpressive example of the species, so my write-up (“Toy Product” was the title) recommended that we take a pass.“But it’s got hundreds of customers!” responded the Executive Suite. “It must be good!” All of my instincts said, “Run very fast.” But management was fixated on what they expected to be a rich maintenance revenue stream, so they bought the backup app in spite of my protests. Then “Wes,” one of our most talented programmers, spent eight months trying to reconcile the executables with the source code we’d been given, and hack around all the bugs and black holes. I managed not to say, “I told you so” more than a couple of times.Just as Wes was finishing that task, another product presented itself for acquisition. This one, an image-storage-and-retrieval system, was brand new, but its creators promised us that it was completely finished and market-ready.I had nothing to do with the evaluation this time. The guys who’d built the product came on-site and installed it. It worked beautifully for a few hours, then fell over and couldn’t get up despite everything the developers could think of. For some reason I will never understand, the staffer who’d been tasked with evaluating this turkey still gave it a positive rating, and Acme Codeworks made the deal. This time, though, guess who got saddled with packaging it for sale? Right. I called it Project B, and I wrote hundreds of fixes, performed major surgery, and managed to reverse at least two fatal design flaws. After three months Acme hired a contract programmer, one of the best I’ve ever known, to work with me. The two of us spent another six months hammering that sow’s ear into a silk purse.We were in the process of turning our fairly stable alpha into a testable beta when I got a short memo from my boss. Apparently, the Executive Suite had decided that Acme was spending too much time and money on Project B, so it had just purchased another product that did the same thing … and really was market-ready. Project B was dead. And by the way, I was unemployed.Oh, and the backup product? Acme never even released it. Once Wes had it running reliably, Acme sold it to an even stupider company for slightly more than we’d paid for it, making the thing profitable on paper as long as you didn’t count the blood, sweat, time, and money spent making it work. Acme Codeworks went down shortly thereafter. Nobody mourned its passing. In fact, when Wes and I heard the news, we drank many a toast to its all-too-timely demise. The only one I remember clearly was something about idiots on parade. Software DevelopmentTechnology IndustryData Management