The worry about program wizards
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 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
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
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.
Uche Ogbuji is a consultant and co-founder
at Fourthought Inc. in Boulder, Colo.
He may be contacted at firstname.lastname@example.org.