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, its
a wonder that mainframe users didnt 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 clients 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
clients LAN began to fail during the nightly preparation for the next days
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 wasnt), 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 softwares 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 clients 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 clients 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 Im 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 didnt 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 didnt 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 |