April 2003

Writing Software Right

Companies invest in programs that banish bugs.

By Wade Roush

Much of today's software is built and updated in a slapdash process. Programmers give life to cool new features in quick-and-dirty code, throw the code at a computer to see whether the program runs, and excise the worst bugs, one by one, until the program works well enough to release.

Naturally, many errors evade this kind of testing, and those that remain can create both minor annoyances and such major inconveniences as late January's worldwide Internet slowdown, the work of a self-replicating "worm" called Slammer that exploited a programming flaw in Microsoft's SQL Server software.

That laissez-faire design philosophy is coming under fire. Sun Microsystems, Microsoft, and IBM are all plotting ways to revolutionize the practice of software engineering. Although their strategies differ, the efforts are all geared toward saving time, reducing development costs, sparing programmers the more mind-numbing aspects of software debugging, and-most important for consumers and business users-producing software that works well the first time it's released.

"Our challenge is to get our software to the point that people expect it to work instead of expecting it to fail," says Jim Larus, leader of a software quality project at Microsoft Research in Redmond, WA.

One of the most radical attempts at improving software is under way at Sun Microsystems Laboratories in Santa Clara, CA. Code-named Jackpot, the project aims to overhaul the software-writing tools that have been created by Sun and many other software companies over the past 20 years. Most of these desktop programs comprise an editor to write and manipulate computer code; a debugger to search for the most common types of programming errors; and a compiler to translate programmers' computer code into the ones and zeroes that machines can act upon. The problem is that although these tools are good at finding such errors as misplaced punctuation, they can't see larger structural problems that make code inefficient, says Michael Van De Vanter, who runs the Jackpot group at Sun Laboratories.

The solution: software that thinks about other software. Van De Vanter's team is building an "analysis engine" that reads a programmer's code and constructs an internal abstract model of the software. The group contends that such models will give programmers substantive real-time feedback as they work.

For example, the Jackpot team wants to provide programmers with a kind of meter that continually gauges a program's complexity-a step beyond the primitive measures, such as the number of lines in a program, provided by today's development tools. The analysis engine would detect whether complexity was getting out of hand-creating lots of hiding places for bugs-and would give programmers "an early warning," says Van De Vanter.

Helping programmers visualize their code is another way to battle complexity, he says. It's easy for software writers to nest instructions such as "if x, then y, else z" within other similar clauses-ad infinitum. But "there is a lot of psychological work showing that if they are nested too deep, people won't get it anymore," Van De Vanter says. The visual tools his team is developing would draw on the analysis engine to transform nested structures into easy-to-understand tables, maps, and highlighted text.

In addition, the Jackpot researchers are designing a debugger that doesn't simply find errors in programming syntax-a missing semicolon in a line of Java code, for example-but also identifies general instances of good or bad programming. "People tend to write code in predictable ways: the analogy in natural language is idiom," Van De Vanter explains. "We want something that will monitor for bad idioms." Widespread implementation of Jackpot at Sun is "several years out," he says, but the researchers plan to test it soon with Sun programmers.