|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
Ive 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. (Dont tell Bill Gates where I got the BASIC papertape). Since then, Ive 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.
Thats a lot of systems to work with, and luckily, I didnt have to master more than one or two at a time. But now Im working with the development of a number of new tools, as well as the evolution of Apples 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 Apples collaboration with IBM, including Kaleidas ScriptX and Taligents object-based system; as well as new developments coming out of Apples advanced technology group (like SK8) and other Apple divisions (like the Newton Toolkit and the Apple Media Kit). Thats as many new tools - simultaneously - as Ive 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 its a full time job just to follow whats 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 theres 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.
Whats 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, youd think that people would minimize risk, and pick one or the other. But its 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 theyre 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 thats competing version by version in the marketplace isnt 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 dont have competition, who dont 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 doesnt 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 shouldnt 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.