Charles Simonyi has spent his professional life building software applications.

While at Xerox Palo Alto Research Center, he developed the first WYSIWYG (what you see is what you get) word processor, called Bravo. He joined Microsoft in 1981 and headed up the development of the company's major software applications, including Word and Excel.

Now, Simonyi is focusing on building software for building software. His company, Intentional Software, plans to deliver programming tools that reduce the discontinuities among the various stakeholders (domain experts, designers, IT staff members, lawyers, programmers and others), which cause software projects to lose the design intent in the development process.

Simonyi: My conclusion is that there is a structural, systemic problem with the creation of software. Of course, it's very frustrating because our brothers in hardware celebrate Moore's Law. Now, we have three Moore's Laws--one in processors, one in memory and one in bandwidth. Software is the opposite. We don't celebrate Moore's law; we commiserate over the continuing software crisis. That's why I always say that software is the bottleneck on the digital horn of plenty. It's so obvious that there is a giant gap between the processing capabilities of the machine compared to actual services it provides.

ZDNet: You are tackling the software development bottleneck problem. Can you elaborate on the problem and how you plan to solve it?

Simonyi: The goal is to do something about the bottleneck, to analyze the systemic problem and redeploy the resources in a way that helps resolve the problem. Tools have to be involved--that's the business proposition for our company--but they have to operate in a new relationship between subject matter experts and the programmers.

Currently, the key element to any killer app is what the application does for people. In health care, for example, helping doctors with patient care is a tremendous opportunity. You need subject matter experts, like doctors and health care administrators, who understand the issues of their domain. The biggest problem is that what a subject matter expert is trying to accomplish is not expressed in any machine-processable form other than code. The code is really the first truly precise description of the problem. The intent of the subject matter expert, however, is not apparent in the code.

ZDNet: What do you mean by the "intent is not apparent in the code"?

Simonyi: I make a semi-joke that programmers are steganographers; they take the wonderful statements of subject matter experts and then they create thousand of lines of code that effectively contain the information, just like a picture of a flower might contain a secret message of one sentence. That is the structural problem; the intent has been lost or obscured, and once it has been lost, then the problems start. To do anything to the program - to fix it, to improve it -- the intent has to be recovered first, which is what programmers do all day--constantly struggle to recover the design from the code.

These are industry-wide structural problems. Quality software is achieved today only at a cost that is not proportional to the size of the problem. Any change in an application - even changes that have to do just with the domain, not with computers - must still involve a programmer and software knowledge.

ZDNet: Does the cross-training of subject-matter experts and programmers result in better software?

When people talk about end-user programming, even using Smalltalk or Logo, you are attempting to teach programming semantics to the subject matter experts, the idea of variables, state, and all those things you learn in programming 101, 102, 103 and 104. How is that going to help anyone? The process will be still hard, and you are trying to get a subject matter expert motivated to become a programmer.

It brings us to this absurd process of people proposing new subjects that programmers should learn. Where is this going to stop? Is the solution to burden the programming curriculum even further? Should programmers be taught accounting or medicine? We shouldn't build our future by piling on more tasks--that's not how Moore's Law has been accomplished. Semiconductor manufacturing was not improved by exhorting workers to do a better job, wash their hands more often or put in longer hours. It was accomplished by mechanizing a greater and greater portion of the process.

ZDNet: How then do you narrow the gap or increase the fidelity between the design intent and the actual programming?

Simonyi: First, we need to push the boundary of computer activity further upstream, and second, we mustn't lose the design intent. The other stuff of end-user programming is not the goal. This gets us to the mission of Intentional Software: We want to improve software development by making the code look like the design. We don't lose the intent and move the processing upstream.

ZDNet: Are you talking about business process modeling and XML (Extensible Markup Language) Web services?

Simonyi: The business model is not code--it has no variable or objects. It has business concepts, abstractions that the subject matter experts are familiar with and have created. Basically, it's the sketch on the napkin. It's marketing speech. It's not scientific, but it is transformable and therefore it is a great example of intentional software.

XML is not a language in the sense of a programming language. XML is basically a computer-exchange syntax. We might as well call it ASCII (American Standard Code for Information Interchange). If I said we would encode your business rule in ASCII would that help the discussion? It doesn't matter if it's encoded in ASCII or XML--the issue is what are the business rules and what do we do with them. Without ASCII or XML, we couldn't do this (create applications), just like we couldn't do it without silicon, but it's not the essence of the idea.

ZDNet: XML is important, but it's not the underlying concept. What is the essence of the idea?

Simonyi: The final code necessarily includes software-programming ideas, which the stakeholders should not be burdened with or are unwilling to bear. As meta-analysts of the process, we (Intentional Software) don't want to burden them. Then what language should they use? The answer is that they should use their own language and build their own model. But what's wrong with that model? The only thing wrong with that model is that it doesn't run. That's where the programmers come in.

ZDNet: If stakeholders, other than programmers, are using their own language to describe the goal of an application, how then do programmers take that input and turn it into machine-readable code that preserves the original intent?

Simonyi: For the sake of argument, assume that we would ask the subject matter experts to write a nice PowerPoint presentation and give it to programmers so they can write the software. That would be a very modest improvement over current practices, which insist that the contributions of subject matter experts are organized in a decent way.

Our proposal goes further. We don't ask the programmers just to read the presentation and write a program. We'll ask the programmer to write a program that reads the presentation and writes the program! We are making a little twist to our request to the programmer: Don't convert the design into a program by hand, write a generator to write the program. We will be actively supporting the process by giving the subject matter experts a CAD (computer-aided design)-like program that the generator can read its input from and process it easily and without loss of information.

Another way to think about it is that the programmers you would have employed anyway to solve your problem are now creating a domain-specific language for your problem. Programmers will admit that every big program is a language of its own. Microsoft Word is written in C++, for example, but if you want to work on it, your colleagues won't just ask if you know C++. Knowing C++ will get you 1 percent of the way toward learning about how Microsoft Word works. The other 99 percent is to learn all about Word's procedures, services and data structures, which all have names, relationships, internal logic and a kind of syntax.

The programmers are subject matter experts in how to turn designs that are not computer specific into a software program. Value semantics, variables, states or decision tables, sequential and parallel logic--all of those computer science ideas are part of their expertise. The design has to be expressed in those ideas to run on a computer.

ZDNet: Can you elaborate more on how the role of the generator compares to traditional programming methods?

Simonyi: Similar to today, you would sit down with some programmers and hammer out the issues. The result would be similar, except you would work on a somewhat higher meta level, and you would focus on what each of the different people would contribute. Some people would contribute their expertise in the subject matter and others, namely the programmers, would contribute specific implementation knowledge. These contributions would be expressed in terms of a generator, instead of as a single instance of code.

ZDNet: What does it mean to express a program design in terms of a generator? What is the benefit in the software development process?

Simonyi: A generator is in effect an executable representation of the more mechanical portions of a programmer's work. By asking the programmers to write generators (and of course enabling and supporting their doing so), they do not have to repeat the same transformations every time the problem statement is changed or improved by the stakeholders. For most changes, the stakeholders simply edit the problem description (on the CAD-like program) and re-run the generator. This moves more of the activity into the machine realm: the result of the changes will be implemented in seconds instead of weeks, and for millicents instead of thousands of dollars, and without implementation bugs, instead of the bugs that any direct manual involvement would inevitably cause.

We use automatic machines to manufacture jet engine turbine blades or silicon wafers. We cannot let humans touch these artifacts, not just for cost reasons, but especially because the needs of great repeatability and precision can only be provided by machines. It is OK-- and even necessary--to let skilled engineers and mechanics adjust these automatic machines, just like it is OK to let programmers create and adjust the generators. Because the programmers are one level away from the production code, any errors they make can be detected before they have an effect on production code--just like a misaligned turbine blade-making machine would never be allowed to produce production blades.

ZDNet: How is writing a generator different from writing a program?

Simonyi: Writing a generator, in the first approximation, is exactly the same as writing a program, except you put a print statement in front of it. Instead of saying "I=1," you say "Print I=1." Of course, you make "I" a parameter to those generators and make it depend on some aspect of the design, but you would have to account for those considerations even if you wrote it by hand. Writing a generator is not different intellectually from writing the code itself. It's certainly not easier, but the benefit comes when you change anything, and you always make changes.

ZDNet: What are the specific benefits of writing a generator beside flexibility and cost savings in making changes?

Simonyi: The people involved in the development process are effectively the same, but their work is factored differently. People are more empowered and more specialized. For example, programmers don't have to care about the subject matter, only about the shape or the schema of the subject matter. Compiler writers, for example, don't particularly care if they are processing hydrodynamic code or healthcare code, they just compile. Similarly, the subject matter experts don't need to know anything about programming--they just describe what they want in their own terms. Subject matter experts are more empowered to create improvements to their software products, in many instances without having to interact with or wait for programmers--as long as they don't change the shape of their expression.

ZDNet: What do you mean that subject matter experts don't change the shape of their expression?

Simonyi: I should have said the schema. They are not introducing new ideas or rules that weren't mentioned before in the design.

ZDNet: Is that similar to business process modeling today?

Simonyi: It's an instance of this concept, but we are at a different meta level with the tools for supporting that kind of modeling activity. For example, business-modeling people have no energy left for creating editing tools that enable groupware, user interfaces, presentation capability, multiple projections and other features. Their forte is to analyze the business vocabulary and consult with the subject matter experts in a particular domain.

ZDNet: Can you be more specific about the tools to enable the higher-level modeling or schemas that are handed off to programmers?

Simonyi: We are talking about a very high quality PowerPoint- or CAD-like tool. There are many technical issues, such as being able to represent chicken scratches in a way that is easily processed by a generator as well as edited and maintained by multiple people. We are also talking about code bases that are millions of lines long and legacy issues.

ZDNet: How rigid does this type of tool used by the subject matter experts to express their ideas have to be so that a generator can consume it?

Simonyi: I think the requirement is that the CAD-type editor must maintain the structure, or "intention," of the input, and then it must present it to the generator through a consistent API. By maintaining the structure I mean that if some elements of the input were intended to be grouped, for example, this intention must appear in the API in an explicit and precise form that does not have to be guessed heuristically or from incidental details, such as formatting or juxtaposition. Besides grouping, referencing, parameterization, mapping, and a number of other general relationships between design elements must be maintained by the editor.

ZDNet: How do aspect-oriented programming and design patterns fit into what you are doing?

Simonyi: Aspect and design patterns are another validation of the value of raising the level of intentionality and abstraction. They describe an incremental path to where we want to go. Incrementally, with aspects and design patterns, you can look at an existing code base and by refactoring it, raise the level of intentionality to a higher level. The implications are tremendous. More and more programming activity can be moved into the machine realm, increasing productivity and quality accordingly.

ZDNet: In another interview, you said that Intentional programming techniques could reduce software bugs to one in a million compared with an estimated 150 in a 1,000 today. How does what you are doing make that possible?

Simonyi: I was saying the obverse. If we want to reduce failure rates to one in a million, we have to use mechanical means. How do I know? Look at the failure rate of compilers--it's much less than one in a million in generated instructions. In terms of the number of bad instructions generated compared to the total number of instructions, it's probably in the 10 to the 15 range. If anything goes wrong, it goes wrong very badly in a grander, royal way and then it is quickly fixed. In manufacturing, it's exactly the same. Turbine blades are made completely automatically, but not just to reduce the price (they are still a pricey item). We could afford the craftsmen, who could carefully file and hand fit the turbine blades, but we wouldn't reach the required reliability. We were forced to automate the manufacturing to get quality, and software is going down the same path.

Domain bugs aren't reduced, however; an administrator can put in a bad rule. But you have quick turnaround for fixes because you have domain experts who can evaluate the output. We are much more comfortable as a society with domain bugs rather than implementation bugs. Historically, the bottleneck had to do with implementation bugs.

ZDNet: Are you developing a language that the generator would use?

Simonyi: The generator is just a program, written by programmers in C#. There are a number of important data structures that are internal to the development process, such as the interface between the design and generator. It certainly has to be richer than ASCII and have the same powers as XML. I am a big fan of XML, but it is just a technological part of the solution, not a conceptual model. UML [Unified Modeling Language] is much closer to what is needed, but I wouldn't even talk to subject matter experts about UML. What does UML have to say about privacy concerns, for example? Do you write a petition to IBM [which acquired Rational Software, a company that pioneered UML usage] to include privacy in the next version of Eclipse? If you have privacy concerns, you should be able to write them down in you own terms.

ZDNet: Can UML be used to capture the design intent?

Simonyi: UML can be used to describe many things about a system, but it is a partial solution with many limitations. First, it is not the conventional notation of the domain experts--not for administrators, accountants, human factors experts, and so on. Second, the implementation details are still described in static code. What happens when one or the other or both changes? With intentional software, there will be no limitation on the nature of the domain notation, and the implementation will be expressed in terms of a generator, which can be simply re-run if the design or implementation, or both, change.

ZDNet: What does the generator include for dealing or interfacing with a schema produced by domain experts?

Simonyi: The schemas represent the agreement between the subject matter experts and the programmers of how they communicate. They have to be hammered out in conventional meetings and negotiations, but this is much better than having to do the expensive interaction for the whole system, as used to be the case. The CAD editor can be an excellent schema editor as well.

ZDNet: How will the domain experts interact with the system?

Simonyi: There are domain specific forms, diagrams, tables, rules, and there has to be multiple projections on the design or the code. Multiple projections is a fantastic concept from computer-aided design. It means you could see an airplane, for example, from multiple viewpoints, such as the aircraft's skin or the inside of the cabin. In healthcare applications, for example, you would want different views: large scale UML-like detail, how different entities relate to each other, or who can see what in terms of access privileges.

With multiple views, the whole notion of syntax will be gone. People will see how silly the whole notion of fixed syntax is. The fundamental shift is that you don't have dependency on a predefined language. The system has no preset syntax. Modifying a language when you have fixed syntax is next to impossible, but generators do not depend on fixed syntax.

ZDNet: In 1997 you said in an interview in Forbes that Java would be totally forgotten. It would be significant only to vendors with tiny market share. That hasn't turned out to be the case.

Simonyi: I was talking in the very long term. Thirty years from now nobody will remember Java and everyone will still know Microsoft.

ZDNet: Will intentional programming concepts improve software development within existing programming, such as Java or C++?

Simonyi: They will benefit from having more design intent showing up explicitly in the programs, such as expressing cross-cutting aspects of the design as with AspectJ. The structure of popular design patterns will be graphically more explicit. Today, the structure of design patterns is implicit, or at best, expressed in informal comments.

ZDNet: Are you designing your own tools with the concept? We are doing it in moderation. Bootstrapping a two-edged sword, we are dancing on one of those edges.

ZDNet: When do you expect to have design tools and a generator interface in the marketplace?

Simonyi: In 2005. The first applications can be quite modest. We are in the technological phase now, and we don't have a first application in mind. There are many possibilities, such as code re-factoring (taking legacy code and extracting and re-expressing design patterns), developing user interfaces for consumer electronics products, embedded systems for autos or help systems. For those kinds of systems, the functionality--the intention, or use cases--are pretty much given. But, imagine if the creative people could experiment with a large number of different expressions of that given intent without the delay and cost of re-involving the programmers at every attempt. I am willing to bet that the results would be spectacular, and that the industry would be eager to use a tool that could make that possible.