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
