Software: The Other Side of the Story
In the July issue of MHM,
I called for users to hold software companies to a higher quality standard.
Soon thereafter, The Code Red computer worm struck, further proving the point.
This worm attacked Microsoft’s Windows 2000 and NT operating systems, and
according to some estimates has cost companies more than $1 billion and
hundreds of man-hours to fix.
Now others, including the FBI and some within the software
industry, are calling for better code. It’s disappointing to hear it
admitted that many, though not all, software programmers write code fast and
cheap, knowing they can fix it later. Here’s a quote from Frank Hayes,
senior news columnist at Computerworld,
“At this point, users accept a pretty high level of crashing in
applications and even whole systems. And today, code-and-patch is the order of
the day in corporate IT shops, at big software vendors and even in the schools
turning out our new “software engineers.”
Some users are suggesting that vendor-customer contracts
call for recompense should software bugs or vulnerability result in lost
profits, lost hours or bodily harm. That’s a good idea. Customers should
start screaming “show me the money.” It’s too bad that the
incentive has to be that it’s more expensive to be lazy than it is to be
disciplined.
Software companies respond, however, that they do try to
catch problems before they release programs to customers or the market. They
test their code and correct bugs when found. And they do adhere to industry-approved
coding standards. Even so, the question remains, how come bugs or
vulnerabilities still get through?
There is an answer. As a reader wrote in response to my July
column, the vendor is not the sole culprit for software quality problems.
Recompense may have to be a two-way street.
The other culprit is the customer. There are no innocents in
business. How often do customers make it difficult for vendors to do their job
properly, and the key word is properly?
In these “everything must be done yesterday times,”
how often do customers shorten delivery dates? How much money do customers try
to shave off the price of a program to save a few bucks? And what is that
negotiation costing in terms of product testing, integration and features?
Sorry, customers, but if you nickel and dime the price, you really can’t,
in good conscience, shout your outrage for vulnerable code.
Thus, blame for software vulnerabilities can be laid at both
parties’ doors. Is this the price we pay for making software a commodity?
Is this the price we will pay if we turn every material handling system into a
commodity?
There’s got to be a better way. And there is. Vendors
and customers must work in a partnership. Much software may be commodity
priced, but it’s an increasingly crucial piece of any business operation,
and should be respected as such. That means vendors don’t try to get
every nickel and dime out of their customers and customers don’t try to
get every nickel and dime out of their vendors. Otherwise, you both lose.
And finally, in the wake of the events of September 11, it
would be näive and foolish to ignore the possibility of cyberterrorism.
Don’t take control and software security for granted. Vigilance will
benefit everyone.
Leslie Langnau
senior technical editor
llangnau@penton.com