Say No to Bad Code

Opinion: Clean software at the start will save time and money—not to mention customers—down the road.

"So, Charles, tell me: How are your computer systems running?" "Quite excellently, James, quite excellently. For months now, Ive seen neither hide nor hair of a security problem or vulnerability in any of my software applications."

"Thats splendid, Charles, just splendid. Of course, things have been grand for all of us since users and companies put their foot down and forced software developers to start producing clean, concise, secure code."

"Ah, yes, James. Remember those silly old days when we were constantly patching systems and scanning the news for problems poised to affect our applications? I shudder to think of all the money I invested in patch management systems."

"Well, things are much better now, Charles. But enough of this computer talk, Babbage, I do believe its cocktail time. And, I say, look whos here to join us. Its Alexander Hamilton, Daffy Duck and the young Elizabeth Taylor."

What? Who? Ahem, sorry about that—must have nodded off.

And, boy, was that a crazy dream. Like anyone would believe that software developers would ever put a premium on outputting secure code.

I mean, why should they? Year after year, month after month and week after week, things just continue to get worse. And, incredibly, IT managers and executives seem to care less and less.

In mid-December, I received my regular mailing of alerts from The SANS Institute. The alert indicated that the week of Dec. 13 was the worst for new vulnerabilities since SANS had begun tracking them. One would think that this would be big news, but it wasnt.

But why should we expect it to be? Face it: The bad coders are winning. Theyve convinced users and companies that bugs, security holes and patches are inevitable, and everyone just shrugs their shoulders and accepts that—no matter how bad things get.

Click here to read about new high-risk vulnerabilities in Microsofts Internet Explorer and the open-source Mozilla browsers. But it doesnt have to be this way. All of us have seen even large, complex applications with source code thats clean, free from bugs and secure. All it takes to write good code is the desire to do so, but there really isnt any incentive for software companies to write clean, secure code.

Youll never get the marketing people and executives to admit it, but get some of the developers at these companies to sit down for a drink, and theyll tell you that hitting deadlines, outputting lines of code and adding features are all ranked by their powers that be well ahead of writing good code.

And bad code, bugs and security holes will continue to increase unless customers of these applications force the vendors to change. And the most effective way to do it is to hit them where it hurts—in their pocketbooks.

Its funny. Many companies insist on uptime requirements and support levels, but these requirements mean very little to the bottom line if they arent met by the vendor. But bugs and security holes are guaranteed to cost your company big money—not just in downtime but in IT worker hours and additional software costs, such as patch management systems.

What companies need to do is start putting code-quality requirements into their software contracts. Set a base line for acceptable bugs and vulnerability events in the software. (I would go with one per quarter, but your needs may be less strict than mine.) If the software exceeds these thresholds, the vendor would have to start forking over cash.

Of course, vendors will complain that software is new and different and shouldnt be held to these kinds of requirements. All technologies are new and different at first, but they have to mature some time. At some point, cars were made so that they stopped breaking down every 50 miles, and electrical systems were designed so that they didnt regularly cause house fires. Software has had plenty of time to mature likewise, and the expectation for quality is overdue.

Some may say that Im dreaming and that software vendors will never be able to cut down on bugs and security holes. But Ive seen good, clean code, and I know its possible for any application.

And, if the Red Sox can win the World Series, then anything is possible.

Wait a second, that did happen, didnt it?

Labs Director Jim Rapoza can be reached at jim_rapoza@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.