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.

While Sun is just beginning to explore advanced software-development tools, programmers at Microsoft have already come to depend on them. To get a handle on bugs in its Windows 2000 operating system, Microsoft paid more than $60 million in 1999 to acquire Intrinsa, maker of a bug-finding tool called Prefix. The program, which sifts through huge swaths of code searching for patterns that match a defined list of common semantic errors, helped find thousands of mistakes in Windows and other Microsoft products. But Prefix is slow and processor-intensive, requiring days of server time to analyze all of Windows. And because the bugs on its blacklist are “hard-wired,” the program has to be rewritten before it can find new types of errors, says Microsoft’s Larus.

To solve those problems, Microsoft is developing a new flexible version of the program. Like Sun’s analysis engine, the Microsoft technology runs on programmers’ desktops and transforms code into abstract structures that can be examined for trouble spots. But the program also allows the thousands of Microsoft programmers to create their own plug-ins that search for errors specific to the type of software being written. Although Microsoft is still refining its program, the company is already considering sharing the tool with companies that make programs for Windows.

And one step beyond these solutions is an experimental bug-finding tool called Slam, which is designed to catch every last deviation from a general programming rule. For instance, whenever programmers have put software “locks” on data to prevent interference while a certain section of their code is using the data, they should make sure to remove the locks before other sections of code take over. Slam can explore every conceivable path in a program’s execution to make sure this happens. Slam is “complete,” says Larus. “If it doesn’t find this error, you know there aren’t any.”

Not all the ideas being pursued are technological. Some simply aim to get people together to solve problems. Two years ago IBM contributed $40 million to launch Eclipse, a nonprofit network of open-source software writers who are cooperating on the creation of a highly integrated development environment with built-in tools for creating software that runs on almost any operating system.

The essence of the project, says Eclipse board of directors chairman Skip McGaughey, is its democratic, open-source design process. “The general feeling,” he says, “is that when the design stage is done in the open with many, many people participating, the odds of getting a design right are orders of magnitude better.”

There’s no way of knowing whether a more democratic engineering culture or the sophisticated debugging solutions now under investigation by software companies might have helped programmers catch the kind of oversight the Slammer worm exploited. But as code analysis technology itself grows more powerful, the payoff should be more reliable software for everyone. Says Microsoft’s Larus, “I believe the only way we’re going to get software to be acceptably better is to apply better tools to it.”