Refactoring the business

Last week's column[1] provoked quite a few thoughtful reactions, including most notably this one from Ward Cunningham:

"There is a huge opportunity lurking up ahead. The enterprise guys don't know it because they think scripting is for sissies. The scripting guys don't know it because they think business problems are already simple and don't have to be made that way."

Ward is famous for two things. He created the first and longest-running Wiki[2] -- a popular tool for freeform Web collaboration that's now widely implemented on many systems and in many languages. And with his onetime programming partner Kent Beck, Ward pioneered and helped articulate what has come to be called Extreme Programming (XP). Along with related approaches grouped under the rubric of Agile Software Development, XP has acquired all the paraphernalia of a full-fledged software movement. There are Addison-Wesley books about XP, and there's an XP/Agile conference[3].

The tenets of XP include programming in teams of two; writing unit tests first; continuously integrating, testing, and refactoring. Here is Ward's refreshing take on refactoring: "It's just a buzzword for writing it as best you can, discovering a better way, and then changing it to be that better way."

There is much debate about whether and how to apply XP to enterprise projects. My own take is that sometimes it's the right thing, sometimes not, depending on both people and projects. But the opportunity that Ward sees ahead transcends the XP debate. In a nutshell it is the opportunity to script the enterprise in business terms as well as in IT terms.

Modern scripting languages have two important properties that qualify them for the task. First they use fewer tokens (words) to express concepts. "When you look at a program and try to reason about it," says Ward, "the fewer the tokens, the faster you can reason about them -- that's important." Second, their powerful and fluid object models support continuous refactoring. Ward says it plainly: "You get to make the words say what they are."

What they are, increasingly, is business processes. And here we run into a major disconnect. To the enterprise, scripted solutions look like one-offs, not strategic systems designed to high standards of quality and able to evolve along with the business. What the enterprise folks don't get is that scripted systems can be engineered to meet these requirements. So they lean toward C++ and Java, and then rely on powerful integrated development environments, like Eclipse and IntelliJ IDEA, to make fluid refactoring possible. These tools can work very well. "They're complicated," observes Ward, "and you have to learn how to work them -- but boy, when you do, they make those languages start to feel like scripting languages." On the other hand, he asks, "Why should we need heroics in the IDE to correct for misguidedness in the language design?" It's a question of suitability for purpose. "If the purpose is to continuously evolve programs for business, then what's suitable is to have clean object models that are easy to read."