Everyone's a Programmer

Few software experts have had as revolutionary an influence on the development of computing as Charles Simonyi, and few have been so richly rewarded for their efforts. As a scientist at Xerox’s Palo Alto Research Center in the 1970s, Simonyi invented Bravo, the first word-processing program that showed on-screen exactly how a document would look in print-a concept commonly referred to as “what you see is what you get.” Simonyi then joined Microsoft, when it was still a startup with three dozen employees. There he became the company’s chief architect, piloting the development of both Word and Excel. Along the way, he also became a billionaire: Forbes recently listed him as the 209th richest person in the United States.

Last year Simonyi abruptly ended his 21-year tenure at Microsoft to start a company of his own, Intentional Software, which he has, to date, funded entirely with his own money. In one sense, Intentional Software is a modest company with modest goals; Simonyi does not expect to have a product to sell for several years. But in another sense, his goals are so large that the word “ambition” barely does them justice. Simply put, Simonyi wants to save software from its own complexity-so that the true potential of computer technology can at last be realized.

Grand quests are something Simonyi knows a lot about: he left Hungary to study abroad at the age of 17 and-illegally-never returned. While he still speaks with a faint accent, he also expresses his opinions unequivocally, without any searching for words, especially when talking about his favorite subject.

Software “has become a field where we focus on incremental improvements in processes,” he says. “That course is futile, because it can never solve the problem of human imperfection.”

What Simonyi proposes instead is a revolutionary change in how we write software, and even in how we think about software. “Conventional improvements people make come at the expense of forgetting what software is all about,” he says.

Why does software need a revolutionary change? Because today it is a technology in crisis, where its complexity has far outrun our ability to comprehend it. It’s next to impossible to understand what is going on in software whenever a program runs longer than a few hundred lines of code-and today’s desktop software contains millions of lines. What we don’t understand, we can’t fix: 25 percent of commercial software projects are canceled, which meant $60 billion in losses in 2000 in the U.S. economy alone (see “Why Software Is So Bad,” TR July/August 2002).

Even as software collapses under the weight of its own complexity, we’ve barely begun to exploit its potential to solve problems. The challenge, Simonyi believes, is to find a way to write programs that both programmers and users can actually read and comprehend. Simonyi’s solution? To create programming tools that are so simple and powerful that the software nearly writes itself-in much the way that Excel automatically adds columns of numbers or Word automatically formats our documents.

“Software should be as easy to edit as a PowerPoint presentation,” Simonyi asserts. That means giving it just as intuitive an interface.

Simonyi is attempting to solve one of the most fundamental problems of software development, typically expressed as “making the code look like the design.” If he succeeds, users will be able to create high-level designs of what they want their programs to do, which might resemble flow charts more than lines and lines of code. From these designs, code will be created automatically.

As the inventor of the first what-you-see-is-what-you-get interface, Simonyi seems uniquely suited to this challenge. But it’s still a tall order. Some say it can’t be done: people have been trying to create representative models that could automatically generate complex code for about as long as they have been writing software, and they have achieved only the most rudimentary successes.

Others say we have no choice. Indeed, similar if less extreme efforts to simplify and automate the task of programming are under way at IBM, Sun Microsystems, and other industrial and academic institutions (see “Extreme Programming: The Zero G Experience” and “From Artificial Intelligence to Artificial Biology”).

“We are trying to solve ever more complex problems with software,” says Grady Booch, a friend of Simonyi and one of the inventors of the Unified Modeling Language. Like the approach Simonyi proposes, this software language allows programmers to reason about what software should do without having to worry about details at the level of the actual code, whether it’s written in Java, C++, or one of today’s other common languages. Last December, IBM spent $2.1 billion to acquire Rational Software, the company where Booch and his colleagues developed the Unified Modeling Language.

“If you take a look at where we are going,” says Booch, citing emerging technologies such as nanoscale microprocessors, which should make computers vastly more powerful, if only we can find effective ways to write software for them, “you see there is no end state.” In other words, he insists, software needs to keep up with hardware, and the way we write it today, it won’t.

How do you make the code look like the design? First, Simonyi contends, you have to understand what’s wrong with the current practice of programming.

“Programming today is the opposite of diamond mining,” he claims. “In diamond mining you dig up a lot of dirt to find a small bit of value. With programming you start with the value, the real intention, and bury it in a bunch of dirt.”

In Simonyi’s view, software developers are doomed to fail because they need to do three jobs at the same time-only one of which they are well suited for. First, they have to understand the often complex needs of the client-the insurance specialists or accountants or aircraft designers for whom the software is being built. Programmers must try to soak up knowledge that their clients have spent years accumulating. If not a wholly impossible task, it’s certainly an inefficient use of their expertise.

Second, programmers must translate these client needs into algorithms and interfaces that the computer system can understand. Simonyi sees this as the core task of the programmer. But today it’s done poorly: when the programmer has completed the software, there is no way for clients to modify it or even to understand how it reflects their contributions.

Third, in order for the computer to execute instructions properly, programmers must write perfect code-with the precision of a machine. Despite constant claims from software companies about the superiority of their development processes to their competitors’, the fact is that bug-free programming is impossible, since we are not machines. A study at Carnegie Mellon University recently found that programmers average 100 to 150 mistakes per 1,000 lines of code.

Simonyi wants to rid the programmer of the burdens of all of the third and a large part of the first and second tasks. He seeks to not only automate the dronelike parts of programming but also make the programming interface so intuitive that the insurance specialists or accountants or aircraft designers can see their contributions and make improvements by bringing their own expertise to bear, without the programmer as intermediary. Once programmers are freed from the inappropriate tasks that now burden them, they will be able to concentrate on the task for which they are uniquely trained: the design of the program itself.

“The real question is, what are we trying to do with this [piece of] software?” Simonyi says. “That’s what intentional programming will allow us to concentrate on. When you want to create a wonderful system for health care, you should be concerned with the problems of health care and how to solve them. But the way we write software now, the understanding of those problems is lost, because the programmer needs to be concerned instead with how to sort numbers, or how to store data on a disk.”

Programming In Pictures

When you ask Simonyi to explain just how the dronelike parts of programming might be automated, eliminating bugs caused by human error, he will tell you a story about jet engines.

“Think about the turbine blades,” he says. “They have to be perfect. If you were to use the most meticulous craftsman to make them, you still wouldn’t get anywhere near the degree of accuracy you need. You need to create a machine to make the blades. Are humans involved in the process? Of course. You need them to build the machine, and to maintain it and adjust it. Can machines fail? You bet! But they fail in a disastrous way, and you can see it right away and can fix it. It’s the same thing with code! You don’t want humans to touch it. It will have bugs in it! Can humans do something? Yes. They can build the machine.”

What, exactly, would a machine for writing software look like? It would itself be software. But its function would not be to solve the end problem-to perform some new home or office task. Rather, it would be a software “generator,” causing a particular piece of software to be written. Telling the generator what program to write would be accomplished through an easy-to-understand interface, sometimes referred to as a “modeling language.”

The most widely adopted modeling language today is the Unified Modeling Language, which evolved from work Booch and fellow programmers James Rumbaugh and Ivar Jacobsen did at Rational Software-and which is now being developed by the open-source software community under the stewardship of IBM and the other members of an industry consortium called the Object Management Group. The Unified Modeling Language is a system for creating diagrams. It’s intended to let managers of large software projects visualize their designs and make sure they meet the clients’ requirements before programmers sit down to write code in programming languages such as Java or C++.

Simonyi’s vision, and the reason he started his company, is to take the idea of models and go one step further: to link the model and the programming so tightly that they eventually become the same. Programmers and users will be able to switch between many contrasting views of the model they are creating, and revise programs at will simply by tweaking the models (see “Just-in-Time Programming,” below). It’s something like an architect being able to draw a blueprint that has the magical property of building the structure it depicts-and even, should the blueprint be amended, rebuilding the structure anew.

Just-in-Time Programming: In this hypothetical intentional software program from a “just in time” auto parts ordering system, option packages run across the top, parts numbers along the left. Any changes a factory manager adds-say, information for a new model year (pop-up box)-would be automatically reflected in the software code.

“It goes all the way back to the notion of what you see is what you get,’” says Gregor Kiczales, who left his part-time position at the Palo Alto Research Center last year to cofound Intentional Software with Simonyi but has since returned to his longtime position at the University of British Columbia in Vancouver, where he is a professor of computer science. Kiczales champions a programming technique known as aspect-oriented programming, which allows programmers to edit all instances of related commands quickly, even within a very complicated program-just as a word-processing program can locate and replace every instance of a misspelled word. It’s a technique that will support the underlying architecture of intentional programming. “The idea of intentional programming is, what if we did that not just with word processing, but with programs?” says Kiczales, who remains a consultant at Intentional Software.

Simonyi describes the new model for generating programs as looking very much like a PowerPoint palette, which anyone can use to create presentation slides by pasting text, charts, or images into different sections of an intuitive virtual workspace. But Intentional Software also believes that different types of problems may call for different interfaces, to meet the needs of different clients. Scientists working with computer simulations, for example, might want to use a generator programmed to mechanically translate mathematical descriptions into the corresponding code.

The kind of software Simonyi envisions will not only relieve tomorrow’s programmers from the need to behave like machines; it will also enable experts in a given field-insurance, accounting, health care-to make their own changes to their software, easily and without the constant aid of a programmer. Suppose you are a corporate accountant using custom financial software, and a new tax law is passed, Simonyi posits. “You can edit the description of what you want to do on your own, and now you run the generator again. You don’t involve programmers again. The generator runs at computer speed, about a billion times faster than human, and a billion times more precise, and you get your change.”

When these tools are developed-and even the ever optimistic Simonyi says it will take at least two years for his company to put a product on the market-the simplicity they bring to programming will not be their only benefit. They will also allow programmers to build software of a complexity we can’t approach using today’s methods.

But Simonyi’s colleagues and competitors have their own, often very different ideas about how to use modeling to save software from the burden of its increasing complexity. There’s Booch, for example, who is hoping to enrich the Uniform Modeling Language by building in a broader version of Kiczales’s “aspects,” so that, for example, functions like security and authentication would automatically weave themselves through entire software systems. He’s also involved, he says, in “finding ways to represent larger and larger abstractions”-that is, going beyond models of individual programs to models of the overall architecture of huge software projects.

“Writing software is fundamentally a very complex problem, and it’s getting worse,” says Booch. “We’re routinely writing applications now that have several million lines of code. To do that you have to build in an illusion of simplicity. Models let us do that.”

James Gosling, a research fellow at Sun Labs and the inventor of Java, is another recent convert to modeling. But again, the emphasis of his research is different. Recognizing that the software industry constantly reuses old programs, Gosling proposes finding a way to plug existing code into a modeling tool that will represent it graphically, rather than requiring programmers to pore over millions of lines of text. Theoretically, we could feed all our old, bug-riddled programs into such a tool, examine their underlying design, and identify their logical flaws.

“Like most programmers, I’m a big fan of starting over,” says Gosling. “But people almost never have that luxury. We’re building a tool that will read a very large system, say, two or three million lines, and will make it easier to understand.”

Code-named Jackpot, the project is still small, well outside Sun’s product development process. But it’s something that both Booch and Simonyi are enthusiastic about, as it is one more indication that modeling is becoming a force that will move the industry.

When will we be able to generate complex code from models alone? While Intentional Software has not yet marketed products, it plans to make concrete announcements in 2004. IBM’s purchase of Rational and commitment to the Unified Modeling Language, along with Sun’s interest in the concept, indicate that these ideas are achieving critical mass.

The challenges these visionaries are grappling with are huge. Yet their success also feels inevitable, because what they are proposing makes far more sense than believing that we can make a perfect thing out of millions of handmade pieces-a flaw in any one of which can break the whole. Which is exactly what we’re trying to do with software today.

“Software is so flexible, and the promise is so great, and the conventional improvements we’re used to today are nothing compared with what we will be able to do tomorrow,” says Simonyi. “Look what the hardware people have managed to do with Moore’s Law. Now it’s going to be software’s turn.”