Toolmaker Advice
Volume 9
Number 11
Column Tag Inside Information
Advice for the Toolmaker 
Keeping pace with an ever-changing industry
By Chris Espinosa, Apple Computer, Inc., MacTech Magazine Regular
Contributing Author
I’ve been working with development tools for personal computers for almost
eighteen years now. The first development system I used on a personal computer was
Microsoft BASIC on a hand-built IMSAI machine in the summer of 1976. (Don’t tell
Bill Gates where I got the BASIC papertape). Since then, I’ve worked with the Apple I
and Apple II monitor and BASIC systems; the Apple II and Apple III Pascal systems; the
Lisa Workshop, with the original Lisa Toolkit (predecessor of MacApp); the Macintosh
Development System, A/UX, MPW, HyperCard, and AppleScript.
That’s a lot of systems to work with, and luckily, I didn’t have to master more
than one or two at a time. But now I’m working with the development of a number of
new tools, as well as the evolution of Apple’s current ones: future versions of
AppleScript, HyperCard, and Macintosh Common Lisp; the evolution of MacApp into
Bedrock; the cross-pollination of MPW and Symantec C; the OpenDoc initiative; the
tools of Apple’s collaboration with IBM, including Kaleida’s ScriptX and Taligent’s
object-based system; as well as new developments coming out of Apple’s advanced
technology group (like SK8) and other Apple divisions (like the Newton Toolkit and the
Apple Media Kit). That’s as many new tools - simultaneously - as I’ve worked with in
my life. And like everyone else, I have to keep an eye on other tools, like Visual BASIC
and Visual C++, PowerBuilder, AppWare, and on and on.
So I think I have a feeling for how complicated it is for software developers to
follow the tools business. For me it’s a full time job just to follow what’s happening
and why. A developer has to not only do the same legwork, but actually bet money and
resources on those tools. These days, making a bet on which tool to use could be as
important as making a bet on what product to develop or which platforms to support.
All tools developers, including Apple, face a fundamental dilemma. On the one
hand, software developers know that there’s too much complexity and inefficiency in
their current tools, and want something better. On the other hand, changing
development tools and methodologies is a big expense and a big risk - e specially for
companies with large amounts of current code to maintain.
What’s worse is that there are new opportunities - mobile computing, PDAs,
digital multimedia, etc. - that tempt developers to take a different risk to get in at the
beginning of another huge industry. Normally, you’d think that people would minimize
risk, and pick one or the other. But it’s possible that the winners in the next five
years will be the ones who take both risks - who adopt new tools to create products in
new categories.
In talking to developers I notice that the ones that are most aggressive about
adopting object technologies also seem to be the ones that are the most visionary about
the new development opportunities. At first I thought that this was simply the
early-adopter phenomenon; that they’re just being aggressive across the board. But
the more time I spent with them, the more I understood that these organizations were
adopting object technology almost defensively, as an explicit strategy to be able to take
advantage of the new opportunities. And it makes sense. A developer with a three- or
four-year-old application that’s competing version by version in the marketplace
isn’t about to spend a year retooling the application using object technologies, losing a
year of the feature and performance improvements that the installed base wants (and
the competition is providing). Sometimes the only groups who can afford to spend the
time to do it right are the ones who don’t have competition, who don’t have an installed
base, but who intend to break in to a brand-new business.
The lesson for toolmakers, then, is that there may not be much value in helping
people write traditional applications better and faster. Though the authors of those
traditional applications certainly could use the improvement in efficiency, the
competitive environment doesn’t allow them to take the time to retool. These
developers will only adopt new tools that let them take their current code base with
them. New tools that require a developer to start from scratch shouldn’t focus on
creating the traditional, single-platform, monolithic application; those toolmakers
should look to the developing industries of component applications, content authoring,
PDAs, and cross-platform or client/server solutions to find an audience for the new
tools.
Referenced by (1):