Those Pesky PC Software Bugs Abound
There are probably many ways to insult a computer programmer--just try calling one a “propeller head”--but none is more sure to do the job than describing his work as “spaghetti code.”
“Never, never say that,” warns Susan Morgan, president of Softview Inc., a Camarillo publisher of top-selling income tax programs for personal computers. “That’s saying he’s an amateur who doesn’t know what he’s doing.”
But as software programs, particularly those for the personal computer, become ever more complex, the chances increase dramatically that the thousands of strings of code making up a program will end up becoming the electronic equivalent of a heap of knotted pasta. The result: software that can prompt anything from an occasional computer malfunction or benign on-screen gibberish to system crashes and devastating data destruction.
Or, in a word, “bugs.”
And much to the consternation of Wall Street investors and high-tech executives, buggy programs are becoming an increasingly vexing problem for some of the biggest software firms. Bugs, it seems, are creeping in everywhere--and not just in sloppy, poorly designed, so-called spaghetti-code programs. Just late last month, for instance, Torrance-based Ashton-Tate reported a $19.8-million quarterly loss attributed largely to bugs in its most recent database software, dBase IV.
“For the big programs, like dBase IV, total debugging is almost impossible,” says Jeffrey Tarter, publisher of SoftLetter, a Cambridge, Mass., software newsletter. “The possibilities of what can go wrong literally approach infinity.”
Marshall Mosley, a software analyst at the San Jose high-tech market research firm Dataquest, adds: “It’s not like 1982 anymore when you can have a program that does one simple thing. Now if you have a word-processing or spreadsheet program, it has to have graphics. And a database program has to be able to work with lots of other programs. When you have all these tied together with networks, you can bet that Murphy’s Law applies exponentially.”
Consequently, finding and correcting these glitches--a process called debugging--is becoming an ever more important task for software publishers. But this time-consuming and unpredictable work is barely able to keep pace with the problems that are emerging.
Software bugs come in a variety of forms. They can be simple errors committed at the time that a program is written, the equivalent of failing to cross a “t” or dot an “i.” Or they can be the result of more complicated interactions between two or more parts of the program that don’t quite mesh. (Although software “viruses” typically have the same effect as bugs, they are not the same. Viruses are intentionally caused; bugs are mistakes.)
The Kiss of Death
Bugs can also be basic flaws in the initial design of the program. Perhaps a program just doesn’t do the job that it was intended to perform, or an entire batch of internal instructions are omitted.
“Ninety percent of writing a good program is planning it,” Mosley says. “If you do the design work right, you shouldn’t have a major problem debugging it.”
Whatever the cause of the errors and omissions, finding and correcting them in a PC software program these days isn’t always completed before the program is released for sale.
Since the release last Halloween of dBase IV, analysts and users have complained that the 400,000-line program, perhaps the largest and most complex PC software product on the market today, is buggy--a label that can be the kiss of death for any software product.
The most publicized of the complaints focuses on problems with the program’s new language for retrieving information stored in large databases; it seems that the language doesn’t work as it should. Other lapses include the maddening fact that the program’s instruction manual contains information that does not match the program.
“The perception is worse than the reality,” says one Ashton-Tate executive, who asked not to be identified. “But unfortunately, perception always has a grain of truth to it . . . (and) the perception of bugs has dampened sales.”
Analysts and even some Ashton-Tate insiders have said that many of the bugs are the result of the company’s efforts to rush the product to market to protect its market position against hard-charging competitors. When the program--the second major revision of top-selling dBase since its introduction in 1981--was released, it was already several months late because debugging efforts fell behind deadlines.
“It was real sloppy programming, and they didn’t test the program enough to catch it,” says Tarter.
Pervasive Problems
Although Ashton-Tate’s problems have attracted substantial publicity, dBase IV is hardly the only software infested with electronic pests.
Last year, Microsoft, the world’s largest PC software publishing house, ran into persistent roadblocks in its efforts to debug two new versions of Word, a popular word-processing program for both the Apple Macintosh and IBM personal computers. The problems forced delays in shipments of the new product and ultimately caused the company to suffer a jolting and embarrassing profit plunge.
And over the years, Lotus Development Corp., publisher of the well-known Lotus 1-2-3 spreadsheet, and Word Perfect Corp., whose word-processing program of the same name is a perennial top seller, have encountered bug problems.
“It’s a pervasive problem for our industry,” says Robert Franksten, chief scientist at Lotus Corp. “A lot of other businesses suffer from mistakes, but in the software industry, they seem to show up more readily.”
For software technicians, though, sometimes just getting the bugs to appear on a regular basis is difficult.
The easiest bugs of all to correct, says Softview’s Morgan, are those that appear reliably. Once a programmer knows how to trigger the bug, a correction is generally relatively easy, a matter of retracing the sequence of instructions in the program and rewriting the code when the problem appears.
But what about those glitches that appear only sporadically and whose causes defy detection?
Franksten still remembers the hellish time that he had in 1966 finding a bug in a program that he had written. The bug existed; there was no doubt of it. The program didn’t work correctly. But finding the sequence of events that would trigger its appearance seemed impossible. A year after Franksten gave up the search, the bug reappeared by accident and was corrected.
“The first trick is knowing why the bug exists at all,” he says.
Perhaps most vexing of all are bugs that are tied to other bugs. If both bugs are present, the program works just fine. But if one bug is fixed, the other one shows up and fouls up the program.
By far the vast majority of bugs in a typical program are discovered and fixed as it is written. Just as an author reads and rewrites his manuscript as he goes along, a software programmer typically runs and re-runs the code to ensure that it performs its intended tasks correctly.
However, subtle errors take a bit of detective work. Consider the program that seems to work perfectly, but causes the computer to come up with a wrong answer.
Tedious Process
Software analyst Tarter recalls one program for which the rounding off of fractions was improperly coded. When the program operated with a relatively small amount of data, the results were not affected. But with huge quantities of data, the answers were seriously off the mark.
In some subtle cases, the computer operator knows that there is a problem, but its origin is so masked by layers of programming and interaction that only a careful scrutiny of a “data dump” can uncover it.
In this procedure, programmers pour over reams of computer printouts of the program. Usually these are sequences of letters and numbers that bear absolutely no relationship to any known spoken language. The debugger’s job, which can take thousands of hours, is to discover which sequence is out of whack.
Among the most insidious bugs are those that merely cause a program to run more slowly than it should or, worse yet, to lose just a little bit of its memory each time it is operated. Such glitches might never be discovered.
Even finding and fixing the apparent bugs doesn’t guarantee that things will get better. Programmers say the more “fixes” that must be made in a program, the greater the likelihood of introducing new glitches when the corrections don’t work with other portions of the program. This is particularly true in long, complex programs that have several interdependent parts.
“It’s a tedious, difficult and thankless task,” says Philippe Kahn, founder and president of Borland International, a Silicon Valley software publishing house. “But if debugging is a problem at a company, it can be an indication that something is more fundamentally wrong there.”
