The programmer wouldn’t have to be summoned each time some new development in the world of international banking, or any other domain, required a new software feature. The customer wouldn’t feel straitjacketed by a programming language. Everyone would be happy.
Simonyi argues that his approach solves several of software engineering’s most persistent problems. Programmers today, he often says, are “unwitting cryptographers”: they gather requirements and knowledge from their clients and then, literally, hide that valuable information in a mountain of implementation detail–that is, of code. The catch is, once the code is written, the programmers have to make any additions or changes by modifying the code itself . That work is painful, slow, and prone to error. We shouldn’t be touching the code at all, Simonyi says. We should be able to design functions and data structures–which intentional programming represents as “intentional trees”–and let the generator modify the code accordingly. (For a more complete description of intentional programming, see ” Intentional Programming Explained ”)
In 2002 Simonyi assembled a new development team; today it includes a dozen programmers, split between Bellevue and Hungary. They began re-creating Simonyi’s intentional-programming code from scratch and working with a handful of customers to test their assumptions and get feedback. A year ago, inspired by a new insight into how to present multiple views of heterogeneous types of data, they threw out a lot of their code and began again. “It’s creative destruction,” Simonyi says. “At Microsoft, it was fairly hard to do that, to throw away everything. But you have to abandon things that are difficult to extend.”
ThoughtWorks, a global IT consultancy, is one early Intentional Software customer. But ThoughtWorks’ CEO, Roy Singham, says that many of his colleagues at the company were initially skeptical of Simonyi’s new project: “A lot of people look at this and say, ‘Brilliant concept–but it’s unimplementable.’ So we asked some of our best technical brains to go look, and they all came back and said he’s on the right track. Yes, it’s hard. Yes, it’s going to take time–maybe many years. But intellectually, he’s got the thing nailed. It’s the right problem to solve.”
“I’ve felt some frustration that we haven’t got something we can actually use in production yet,” says Martin Fowler, chief scientist at ThoughtWorks. “Charles doesn’t seem to be in a hell of a hurry to ship. But one thing to bear in mind is that he has shipped things in the past–quite dramatic things, with Office.”
The visible fruit of Intentional’s work to date is a nifty tool called the Domain Workbench, which stores a program’s vital information in an intentional-tree database and then offers you many different “projections” of that information. In a demonstration Intentional gave at two conferences last fall, the Workbench–using a feature called the Kaleidoscope–took a series of code fragments and displayed them in a dizzying variety of formats. It didn’t matter how the syntax of the code had been specified; you could view it, and change it, using whatever notation you preferred. You could edit your program as traditional bracketed and indented code, or switch to outline form, or make it look like a schematic electrical-wiring diagram, or choose something called a “railroad diagram,” a kind of flowchart notation derived from old-fashioned train maps. Each view is a translation of the underlying tree–which you can also examine and edit.