VERTICAL TAKEOFF, Part Two

by Wayne M. Krakau - Chicago Computer Guide, December 1996

This is a continuation of my column on vertical-market software, that is, software written to (allegedly) meet the needs of a specific industry. Since the vertical-market software industry itself is heavily populated by what I refer to as "ethically-impaired", which includes both those who are actively unethical and those who simply decline to see the limits of their products or associated services, caution is advised.

I made the transition from "Big Iron" (mainframes) with the naive idea that I would see an end to the constant poor treatment suffered by users at the hands of computer people. After putting up with the lack of business design acumen, absolutely horrific user interfaces, unstable applications, and a paternalistic and, in many cases, downright dictatorial computer support staff, it’s a wonder that mainframe users didn’t switch back to quill pens and parchment to completely avoid technology.

I thought that the availability of easy to use programming tools along with market forces (survival of the fittest) would allow only the best products and companies to thrive. Why would users tolerate these characteristics in a free market? The reason is that this is not a free market. A "free market" requires that information is equally and easily available to everybody. (Hey, I just knew that those MBA classes were going to come in handy someday!) Only those who both have the technical and business background, as well as the appropriate research capabilities are really knowledgeable about the vertical-market software subsection within the computer industry. For everyone else, a computer is just another business tool - a mysterious "black box" designed by a quasi-religious sect of gurus.

My first encounter with bad vertical-market software really set me straight. A client’s credit collection business depended on a particular vertical-market software package that was written using a then-popular database product and its associated language. After a recent upgrade of that software, the client’s LAN began to fail during the nightly preparation for the next day’s calls. (Think about the impact of a collection agency not having the information needed to make phone calls!) The server would crash and lock up completely. The software company claimed that the LAN was at fault.

Since my company designed and sold the LAN, I started looking into the problem. It is very difficult for "application" software (software that does a human-related function such as accounting) to crash a server unless it was designed to run within the server (and this product wasn’t), so I thought that the LAN might really be at fault. After a couple of weeks of detailed analysis, I found some clues that led me to believe that is was the software’s error. I managed to contact the head of development for the database company, and he agreed with my analysis and even filled me in on the details of his product.

A very old, and by then unsupported, version of his database would cause NetWare servers to crash if certain improper programming techniques were used. Correct programming methods would not cause this error. In subsequent versions of his database, the improper programming would be detected and automatically be replaced during the development processes. His solution was to switch to the latest version of the database. Doing that would simultaneously correct the problem, run faster, and make the software product eligible for support from the database company. There was even an automatic conversion routine included in the newest version of the database to accommodate upgrades from very old versions.

I told my client about the situation and he passed that on to the vertical-market software company. They denied everything (stonewall!) and gave him some nonsensical answers that seemed specifically designed to confuse a non-techie.

The next time I went to the client’s office, I called the software company, using a trick that I have since found quite useful. I initially pretended to be a typical low-end computer geek from a computer store. I let the "programming manager" describe all the ways that the LAN was inadequate and all of the "stupid mistakes" that my client’s staff made while using the software. I listened while he boasted of the advanced technology and outstanding programming techniques used in his product, and of the "many" satisfied customers they had. I then led him to a discussion of the details of his staff and their programming and network experience. (I can be very sneaky if I have to be to help a client.)

Then I dropped the bomb. I revealed my true background, including the fact that I had more years experience programming (prior to being a systems integrator) than the cumulative experience of his entire staff! I gave him a litany of programming errors that his company had committed on top of the one that caused the problem at hand. I also got him to admit that his company had been selling a network version of its software for over two years even though none of its employees had ever SEEN a local area network - not even at a trade show! They only tested their software on a multi-user system (one computer with multiple terminals attached) that claimed to be able to run software designed for a network. They felt that this was enough testing to make sure that their product was compatible with NetWare. Forget about ethically-impaired - they were ethically bankrupt!

In an effort seemingly designed to confirm my "ethically bankrupt" diagnosis, the company committed even more offenses. They refused to upgrade their product to fix the bug, claiming it would be "too hard" (contradicting what the database company manager told me). They fixed it by publishing a patch, for which they charged SEVEN HUNDRED DOLLARS! (I hope I’m not the only one who sees a problem with this.) To add insult to injury, they sent my client a bill for technical support charges! This was in spite of the fact that my client had a service contract with them (at $300 per month) which specified "unlimited" technical support. The software company representative explained that my client had used "too much" technical support time that month (gee, I wonder why) and, therefore, "deserved" the additional charge. He also stated that if they didn’t pay the bill immediately, they would be refused all further support. Since my client depended on this software for survival, they paid the bill.

When my client later asked for an extra report, I was unable to help him since the software company encoded their data in a proprietary manner so only they could produce reports. Of course, they charged outrageous amounts for that service. A side effect of this encoding was that it was just about impossible to transition to a competitive product without manually typing in all of the data from this product. The software company made it clear that if they even heard a rumor that we were trying to crack their coding scheme, whether for reporting or transition purposes, they would cut off support. Since there were only a small number of experts in the underlying database, the client was unwilling to try anything. The risk of the software company finding out was just too great.

Two years later, when the software company finally upgraded their software to use the latest version of the database, they demanded that my client also purchase the underlying database update for double its suggested list price. When my client protested that they could purchase the database upgrade from my company (or, for that matter, just about any other reseller) at substantially less than list price, they were again threatened with the loss of all further support.

During these encounters with the vertical-market software company, that company didn’t have the slightest notion that anything they did was in any way substandard or unethical. I hope you are seeing the trend. Next month I will analyze this trend and how to avoid it.

�1996, Wayne M. Krakau