Through the 1990s and into the new millennium–while Microsoft fought its wars with Netscape and the U.S. Department of Justice and rode out the dot-com bubble and bust–Simonyi and his team labored and learned.
Meanwhile, beginning in 2001, Microsoft was pushing the armies of developers who wrote software for Windows to adopt a new programming system called the .Net Framework. Unlike intentional programming, .Net was finished, and it required a less radical break from existing programming techniques. Simonyi itched to take his idea out of the lab and put it in front of customers, but that was awkward under the circumstances. He explains, “It was impractical, when Microsoft was making tremendous strides with .Net in the near term, to somehow send somebody out from the same organization who says, This is not how you should do things–what if you did things in this other, more disruptive way?”
Simonyi had been a company man for more than 20 years. But in 2002, he left Microsoft and launched an independent company. He walked out with a patent-cross-licensing agreement that let him use the concepts and ideas of his intentional-programming research but did not permit him to take any of his old code with him. He would have to start writing a new code base from scratch.
Under the banner of his new company, Simonyi dropped the word “programming” and rebranded his project as “intentional software.” The basic idea hadn’t changed, but now he began to stress the approach’s value to nonprogrammers. Simonyi’s pitch went something like this: Today, only the programmer is able to have a direct effect on the software. “Subject matter experts” or “domain experts”–the people who actually understand what the software needs to do, whether it is medical record keeping, corporate accounting, or climate modeling–can’t make changes to their tools; they’re forced to “submit a sort of humble request to the programmer.” Intentional Software would sell software development tools not just to programmers but to the domain experts who really knew their fields.
Intentional Software’s strategy borrows from a trend in programming known as “domain-specific languages” or DSLs–little programming dialects tuned to the needs of specific disciplines. Simonyi praises DSLs but says they don’t go far enough. They’re hard to create and therefore costly; you end up needing more than one (for a medical billing system, you’d need at least a medical and a financial language); and they’re incompatible with one another. Intentional Software’s system is like a factory for multiple DSLs that can talk to one another.
Here’s how it might work: Suppose an international bank wanted to develop a new system for managing transactions in multiple currencies. First, the bank’s own domain experts would define the system’s functionality, using their customary terms and symbols and identifying the most important variables (“time” or “value” or “size of transaction”) and the most common procedures (“convert holdings from one currency to another” or “purchase hedge against falling value”). Then the programmers would take that information and build a “domain specific” program generator that embodies that information. A separate software tool would allow the domain experts to experiment with different sets of data and ways to view that data as easily as businesspeople today rearrange their spreadsheets.