Columns

The worry about program wizards

• By Uche Ogbuji
• January 31, 2003

About a decade ago, the strangest things began to happen in the world of software development. Into the realm of the supremely abstract art of programming came a group of tools marketed with names beginning with the word ''visual.'' To developers, these tools promised to replace the old regimen of squinting at raw code with the wonder of snapping modules together like Lego bricks. The promise to managers was that they would need fewer developers -- expensive misfits that they are. A key innovation of these visual programming tools were wizards. Wizards ask you a few questions about some coding task, and then automate things for you.

I hardly need point out that these promises were a little short in the keeping. Certainly, in some niches, wizard-oriented programming has flourished, but with heavy limitations. For one thing, wizards mostly work in environments where the vendor of the tool is also the vendor of key support components such as the DBMS, user interface libraries and even the operating system itself, or at least in environments where the vendors are all in close partnership. These vendors have made lucrative markets out of this melding of environments and development tools, and recent platforms such as J2EE and .NET are cunningly designed to maintain such markets.

The XML revolution turns out to have had a strongly subversive effect on this arrangement. XML's openness and relative transparency mean that building systems that bridge multiple environments is much more feasible. XML also encourages programmers to work with gloves off. As an example, before Web services, distributed computing was largely driven by complex tools. Very little of the magic that went into binding applications together was directly accessible to the developer. Even looking at the transmissions over the network would offer no more than a glimpse at what might as well be line noise. Wizards did well in this world by putting a pleasant face on all the mystery.

Web services, on the other hand, transmit simple XML over the wire, which is much more accessible to the developer. Web services mean that the participating systems no longer have to be developed with matching toolkits. The programmer can manipulate all the details of the communication directly, if need be. The disadvantage is that wizards lose much of their luster under this arrangement, and some programmers do miss leaving it all to magic. Recent developments in XML and Web services -- such as the development of XML data bindings and highly constrained Web services -- are aimed at making the world safe for wizards again. There are, however, some reasons for all programmers to be wary of wizards.

Wizards enjoy obscurity and rarely give up their secrets. Gandalf was not one to show his hand even to those whom he strove to assist. John Dee was not one to reveal the secrets of divination, and was indeed a master of cyphers and cryptography. Wizards hide the specifics of the art behind the creation of the code or bindings you need, which robs you of experience that allows you to perform such tasks yourself at times when the wizards may not be available. This is more likely in the sort of heterogeneous environments that are becoming more common. One should not have to steal Merlin's book of spells in order to maintain his magic.

Wizards can be false. The Wizard of Oz sent Dorothy and her band on a hazardous quest with the promise of granting their most fervent wishes if they succeeded. He knew full well he hadn't the power to actually grant the wishes, and rather hoped they would conveniently perish on the quest. Likewise, programming wizards often make the programmer go through elaborate specifications of the desired effect just to prove that they are unable to bring it about. Often, they do produce code that seems to approximate the real need, but in fact turns out to require as much effort in tweaks as the programmer would have spent crafting custom code in the first place.

Wizards don't like competition. The wizard of Menlo Park, Thomas Edison, was notoriously ruthless in his own vilification and exclusion of competitors such as Westinghouse and a host of filmmakers who eventually moved to the West Coast and helped establish Hollywood. Wizards usually build in vendor assumptions and preferences that are incompatible with the wizards used in other systems that need to be integrated. Wizards have proven a very powerful tool for vendor lock-in.

Wizard spells are often short-lived. Harry Potter and Ron Weasley were almost caught by Draco Malfoy when student wizard Hermione Granger's Polyjuice potion started to wear off while ... ah, you get the gist. Even the best code, whether conjured by a wizard or hand-crafted, reaches an end of its useful life at some point. Often such code will need to be understood by later maintainers and those writing updates. Code that is specialized to the application, and closely documented accordingly, is more likely to yield to later analysis.

In the end, there is no substitute for programmer expertise and experience. Wizards do have their place, but it seems that their occasional convenience should not form a backbone consideration for the development of any technology. In particular, it is dangerous to lead developments in XML and Web services with a significant purpose of reviving the great age of wizards.

To read more columns by Uche Ogbuji, click here.