Unplugged: Charles Simonyi

Simonyi describes software as the "bottleneck on the digital horn of plenty." He doesn't believe that training subject matter experts to program will reduce the bottleneck. "We should not build the future by piling on more tasks. Moore's Law improves because greater portions of the process are mechanised. We just need to push it upstream and preserve the design intent of the subject matter experts," Simonyi said.

Simonyi's notion of pushing programming upstream is a PowerPoint-like design tool that allows stakeholders to describe an application in their own terms and then hand it off to the programmers to write a "generator" to produce the machine-readable code. His company will develop tools, taking advantage of recent innovations in aspect-oriented development, design patterns, model-integrated computing and other programming methods. In our interview, Simonyi explains some of the concepts behind intentional software development and how it will pave the way for more adaptable, reliable programs.

ZDNet: What is the problem you are trying to solve with your work at Intentional Software?

Simonyi: My conclusion is that there is a structural, systemic problem with 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 analyse 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 a 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 the code. The code is really the first machine processible, 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 famous 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 it, the intent has to be recovered, 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 at a cost that is not proportional to the size of the problem. Any change [in an application] must involve the programmer and software knowledge.

Clearly have to start with a design and end up with a software product at the other end. In the past and even today, subject matter experts talk to programmers in human-to-human interaction. Then programmers have control of the software artifact, moving to a computer activity in which results are compiled and a software product is created.

People have tried several obvious improvements to the software development process, such as teaching programmers more about the subject matter or teaching subject matter experts more about programming.

ZDNet: Does cross training subject matters experts and programmers result in better software?

Simonyi: When people talk about end-user programming, even Smalltalk or Logo, you are attempting to teach programming semantics, the idea of variables, state, and all those things you learn in programming 101, 102, 103 and 104 to the subject matter expert. How is that going to help anyone? The process will still be the same, 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 or subject matter experts should learn. Where is this going to stop? Is the solution to burden the curriculum even further? Should programmers be taught technical writing? We shouldn't build our future by piling on more tasks--that's not how Moore's Law has been accomplished. Semiconductors didn't improve their reliability and performance by exhorting workers to do a better job, wash their hands more often or put in longer hours. It was accomplished by mechanising 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: What does making the code look like the design or moving processing upstream mean in practical terms? Are you talking about business process modeling and XML 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 and have created. Basically, it's the sketch on the napkin. It's marketing speech. It's not false or ineffective, but it's not scientific.

XML is not a language in the sense of a programming language any more than sketches on a napkin are a language. XML is basically a computer exchange syntax. We might as well call it ASCII. 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, which is a big deal, 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 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 an 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 organised 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 on 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 one 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 versus 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 discuss what each of the different people would contribute. Some people would contribute the structure and expertise in the subject matter and others 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 that only machines can provide. 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 if you wrote it by hand. Writing a generator is not different intellectually from writing the code itself. It's certainly not easier. 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 specialised. 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 writing 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 new software products in many instances as long as they don't change the shape of their expression.

ZDNet: What do you mean subject matter experts not 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 for creating tools that enable groupware, user interfaces, presentation capability, multiple projections and other features. Their forte is to analyse the business vocabulary and consultant 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 scratch in a way that is easily processed by a generator as well as edited and maintained by multiple people. We are talking about code bases that are millions of lines 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, parameterisation, mapping, and a number of other general relationships between design elements must be maintained by the editor.

ZDNet: How does 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 to an estimated 150 in a 1000 today. How does what you are doing make that possible?

Simonyi: I wasn't quite saying that; 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 terms of the number of bad instructions generated compared to the total number of instructions, it's probably in the 1015 range. If anything goes wrong, it goes wrong very badly in a grander, royal way. 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 must carefully file and hand fit the turbine blades, but we wouldn't reach the required reliability. We were forced to automate the manufacturing, and software is going down the same path.

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

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

Simonyi: The generator is just a program, written 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 write it 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. Plus 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. It has no preset syntax. Modifying a language in that context is impossible, but not for a generator.

ZDNet: In 1997 you said in an interview in Forbes that Java would be totally forgotten. It would 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 remember 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 crosscutting 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?

Simonyi: We are doing it in moderation. Bootstrapping a two-edged sword, and 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.