Microsoft's former chief architect has started his own company and wants to transform the way software is designed.
Charles Simonyi, Microsoft's former chief architect, recently left the software giant to co-found Intentional Software Corp. in Bellevue, Wash. The company is developing a notation editor that supports "intentional programming," an approach that embeds the program designer's intent with the code, making it understandable to programmers and nonprogrammers alike.
Simonyi invented Bravo, the first WYSIWYG processor, at Xerox Corp.'s Palo Alto Research Center before joining Microsoft. At Microsoft, he led the development of Word and the Multiplan and Excel spreadsheet programs. Simonyi, who was born in Hungary, also developed Hungarian Notation, a variable naming convention well known to many programmers. Simonyi recently spoke with Computerworld's Robert L. Mitchell about his accomplishments at Microsoft, his plans for his company and software development in general.
Q: You had been at Microsoft since 1981. Why did you decide to leave now? Because there is this tremendous opportunity in intentional technologies. We are trying to provide higher productivity and higher quality of software. In the programming process today . . . much of the design intent is lost. We want to prevent that loss. We want to capture that design information -- the intent of the designer. That's why we call it Intentional Software.
Q: Let's talk about intentional programming. Can you explain what you mean by the need to recapture lost design information? Suppose an architect decides that a fireplace should be centered under a balcony, and that gets encoded in the drawing by a distance of the edge of the fireplace from a wall. Imagine that later on something changes. Maybe the fireplace cannot be delivered and a smaller one is substituted. The dimension -- the distance from the wall -- doesn't convey that information, so the design intent has been lost. People spend a lot of time trying to recover the design intent. This is pretty much what happens in software projects as well as construction projects.
Q: How are you going to solve that problem? If you look at design documents, they are only partly in English. They are very technical, and they do have formulas and charts and tables in them. So one [requirement] is that [the notation] be machine-readable. The second thing is that it has to be as much as possible like the domain notation that people already use.
The tool we are going to sell will be a notation editor that will let you record the design intent as close to the domain notation as possible. The stakeholder ends up doing the design. Then the result, expressed for example in XML, can be transformed by a program generator into the program that will actually run on the computer.
The stakeholders . . . are the people around the software project who are contributing the value to the software. For example, when the domain is health administration, then the people who are experts in health administration are the stakeholders. User interface experts, graphics designers, creative people are all stakeholders.
Q: Is the stakeholder essentially doing high-level coding? There has been an unsuccessful trend of creating programming languages that a nonprogrammer could use. That's not what we are saying. We don't want the stakeholders to write code. We want to capture the design of the stakeholder and treat it like code, which is a big difference.
Q: Will this shift mean another learning curve and another abandonment of existing practices and legacy code? The answer is most emphatically no. I'm not suggesting any new ways of implementing things.
Q: What's in it for IT?
If we make the code look like the design, then programmers will spend less time recovering that design information, because it will be in front of them. The stakeholders can [then] directly interact with the code. That simplifies the programmer's job because they are not going to be the intermediaries.
Instead of writing code for a day, the programmer writes a generator for a day. And at the last millisecond of the day, he runs the generator and gets the code as well. So he'll be just as far along as the programmer would have been before, except now we not only have the code but we also have a generator. So we are one millisecond away from generating the next version and all the other versions that will come after the stakeholders play their creative games.
The benefits to the end users will come as a general improvement in productivity and quality that will come from machine processing instead of the programmer always massaging the code.
Q: When will intentional programming products arrive? We'd like to have a product in about two years. At the same time, it will be important for us to bring out some live artifact in six months that will help us communicate our ideas in a vivid and dynamic form.
Q: Half your development staff is in Hungary. What are the benefits to using a multinational development team? In Hungary, the ready availability of world-class talent means we can expand our development capacity with ease. So that's really the major benefit. The other benefit is that we get exposed to the issues of distributed development, which is a high-value problem that our tools will be able to address.
Also, there's this notion of working in different time zones, which creates an interesting and very positive dynamic.
A team that works in one time zone can pose issues and challenges and problems to the other team, and the solutions arrive the next morning. It's almost like doubling the number of hours in one day, which is something businesses have always wanted to have.