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 - especially 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.