|
|
After I escaped from day-to-day management, I had time to think about Autodesk's strategy and direction. What I found was disquieting. In August of 1988, I wrote this memo to Al Green to attempt to define the issues on the technological side of the company which needed addressing. The roots of most of the problems which were eventually brought to a much wider audience two and a half years later in Information Letter 14 (see page) can be seen here in embryonic form. Those who believe me a renegade leader of a “cabal” or “theocracy of hackers” may find the analysis and recommendations herein rather surprising.
To: Al Green
From: John Walker
Subject: Technological Leadership
Date: August 23rd, 1988
No person who has lived through Autodesk's growth over the last six years, or even a significant part of it, could cling to the fantasy that the process has been a well-planned, steady march to success, regardless of how much our financial results may support that view. Instead, the company has encountered and survived almost all of the crises that befall rapidly growing companies in turbulent markets and has emerged stronger and better positioned for having done so. This process of maturation and tempering can be viewed, however, as lurching from one potential disaster to another, hoping to fix each problem before catastrophe befalls our venture—and that is precisely what we've done, always managing to recognise each crisis in time and act decisively to resolve it.
I am writing this memo because I believe that Autodesk is presently facing one of the most serious crises in its history, a crisis of technological leadership calling for changes in the technical structure, direction, management, and leadership which must occur if Autodesk is to continue its success in the marketplace. This crisis is particularly acute because its resolution will involve restructuring an area of the company which has to date been the least affected by the imposition of structure and professional management as the company has grown, and in many ways is still run as it was in 1983. Consequently, imposing changes in this area inevitably will affect the relationship of founders to the company, the software development group's perception of its role in the company, and the very process by which Autodesk products are conceived, implemented, enhanced, and supported. These changes cannot be made without creating stress and some disruption, but I believe that deferring them will place at risk all of what we have worked for to date, and the great potential which I continue to believe this company possesses for the future.
I believe that Autodesk has long outgrown the kind of passive,
caretaker management which has characterised software development
since the company's inception. I believe that there is an almost
total lack of technological direction to the company's software
development efforts, that no overall design is being applied to
achieve our publicly-stated goals of product line integration, that
resources are being misapplied to company priorities, that a pattern
of abandonment of products once launched![[Footnote]](i/footnote.png){kind=small}
is contributing to product
line stagnation and exposing Autodesk to serious competitive threats,
and that all of these are symptoms of inadequate technological vision,
leadership to implement that vision, and competent professional
management to accomplish the tasks required to reach our common goals.
Addressing these problems before they cause even more serious damage
must be one of the company's highest priorities.
In what follows I will survey the state of the company's product line, focusing on how product design, development, and support are managed. Most of the comments regarding market position and competition, and all of the sales results, are drawn from the August 1988 Marketing and Sales Plan.
AutoCAD Release 10 was conceived as the generalisation of AutoCAD to three dimensions. In early 1987 Scott Heath suggested focusing our previously ill-defined and stagnant 3D project on the goal of first generalising AutoCAD to operations in any plane in space, then extending that base into a modest 3D feature set. A programmers' meeting was held on March 8, 1987 to attempt to make both the short- and long-term goals concrete, and development began shortly thereafter (with significant disruption and diversion from Release 9 final development and debugging which was underway concurrently).
During the development of the product, several major new features were developed and integrated into the product, including dialogue box versions of viewing commands, entity database handles, dynamic 3D viewing operations, multiple on-screen windows, three-dimensional polylines and surface meshes, and an extended memory version of AutoLisp. These features, and several others, were added to the product based on perceptions of competitive products, comments from potential users shown prereleases of the product, general feel for the market, or just at the urging of the developer of the code—in short, in the same way the design of AutoCAD has proceeded since Version 1.0.
Based on a statement that all coding for Release 10 would be completed by April 30th, 1988, a tentative shipment date of June 25th, 1988 was set for the product and announcement was slated for AutoCAD Expo 1988. As the announcement neared, it became clear that major code submissions were still underway—in no sense was the product development close to complete by the originally-scheduled “code cutoff”, and the originally-slated release date was unachievable. As testing of the product progressed, it became evident that several serious upward compatibility issues had been inadequately addressed, and that ignoring these problems in the final product would disrupt existing applications and user-customisation, and as a consequence major effort was applied to implementing FLATLAND mode which attempts to preserve compatibility with Release 9.
A period of reevaluation and slippage ensued, resulting in a current
best-case shipment date more than three months after the original
date, with some programmers remaining very skeptical about the
stability of any product shipped on that date. Now even if the
product slips to November,
it will not break any Autodesk record for
late shipment of a product—Version 2.6 was announced in November
1986 with an internal shipment target of January 1987 and finally
shipped in April of 1987. But in the intervening time the stakes have
risen enormously, and Release 10 is not like Version 2.6. Release 10
is arguably the most important release of AutoCAD ever; for years we
have been assailed for our lack of 3D, and Release 10 constitutes
our statement of just what a “full 3D AutoCAD” means. Version 2.6
was conceived, presented, and interpreted by the market as a minor
update, so it placed much less of our reputation on the line, and the
potential for order deferral if it were late was much less.
With Release 10, we are going forth to do battle with Cadkey, which we have allowed to establish itself as a strong competitor by our lack of 3D capability, and with the mainframe systems coming down, on their own three dimensional home ground. If Release 10 fails to deliver on our promises for it, is seen as slipping from release date to release date, or develops a reputation for unreliability either through user-encountered problems, application incompatibility, or the perception created by product recalls even if prompted by minor problems, it will be a serious blow to our efforts to regain the momentum in the market we have lost during the years our development efforts have ignored 3D features.
In addition, the financial stakes for late shipment and a possible recall of Release 10 are enormous—we have publicly announced the product, promoted it as one of the most significant enhancements of AutoCAD ever, positioned it as part of our major account strategy, and committed to free updates for all AutoCADs sold after Expo, creating both an update liability that grows every month and guaranteeing that any product recall, if one occurs, will be highly visible both to our users and the financial community.
What can we conclude from examining AutoCAD Release 10? The development of Release 10 to date is not a story of mismangement, incompetence, or inattention to detail. It is simply the result of Autodesk conducting its product definition, development, and refinement in precisely the same way we did for Releases 2.0 through Version 9, with similar consequences for product focus, timeliness, and quality risks.
The definition of the features in the product was largely left to the programmers writing the code. Major features were included only because individuals ran off, developed them, and them dumped them into the product stream. Features were coded, in some cases involving significant expenditures of time, then discarded when perceived as unworkable (DDVIEW is one example). Product definition was driven little, if at all, by formal guidance by the marketing and sales organisation, increasing the influence of random encounters with users, developers, and sales people on individual programmers. As an example of this process, Coons patches were included in the product because I had read about them in a book and wanted some kind of easy-to-create sculptured surface to demonstrate 3D surface patches. Making the data base recoverable after a random clobber, considered a major shortcoming of the product, is a project of the same magnitude and was not done because I did not think of it at the time. The following is an incomplete list of features which could have been included in Release 10 by trading off development time with some other features or by assigning additional manpower to the project but which were omitted largely because nobody argued for them. Every one of these features has also been omitted from a release prior to Release 10 by being forgotten until it was too late.
This is not to imply that any of these items are more important than
those included in Release 10, but simply to point out that they
represent the “Release 10 that never was” purely by having eluded
the attention of the programmers while coding, not through any conscious
market-driven decision on what capabilities we need in our product to
defend and expand our market share.
If we seriously intend to compete with Intergraph, IBM, and Prime, I do not believe we can afford to continue to develop our products in this manner.
Based on our evaluation of the Macintosh II, ongoing communications with Apple, the emergence of competitive products on the Macintosh, pressure from dealers, and the intention of major accounts to install that machine, in late 1987 Autodesk committed to developing a CAD product for the Macintosh, and one of our most senior developers was assigned exclusively to the project.
Based on technical considerations which made it appear impossible to directly port AutoCAD to the Macintosh, and also from an understanding that products from other platforms merely ported to the Macintosh were unsalable, Autodesk committed to a multi-man-year development effort with the goal of implementing a new CAD product for the Macintosh. The initial operating capability of the product was anticipated to be at least a year from the inception of the project, and to be a two-dimensional product with the functionality of a much-extended AutoSketch. Feedback from Apple was contradictory; on the one hand they “needed AutoCAD to sell the engineering market” but also wanted a Macintosh-specific product which provided unique value-added based on the application commonality of the Macintosh.
I could not personally believe that Autodesk had so lightly committed to developing a totally new CAD product which, to justify the resources which would be expended in developing it, would eventually spawn marketing, training, support, and development costs comparable to those for AutoCAD, to address a single market whose total size, using the most generous measure, was 10% of the size of the market for AutoCAD. I also believed that in the one year estimated time to market (which I considered extremely optimistic), the window of opportunity to position a product on the Macintosh would close, particularly as Versacad was then beginning deliveries of a product with capabilities similar to those of the product we contemplated and we knew of several other entrants which would reach the market before we could.
In February of 1988, I started to investigate whether it would be
possible, by various means, to port AutoCAD to the Macintosh II.
By February 15th, 1988 I had demonstrated AutoCAD Release 10 running
on the Macintosh II in 5 megabytes of memory.
Immediately this was demonstrated, the previously-committed project to
develop a new CAD system for the Macintosh evaporated and was replaced
by a project to port AutoCAD Release 10 to the Macintosh, while adding
some Macintosh-specific capabilities. While I was happy to see
Autodesk adopt what I personally believed not only a more realistic
but also a more beneficial goal for a Macintosh product, the whole
experience of the definition, destruction, and redirection of the
Macintosh product does not show Autodesk's formulation of strategy and
technical decision making in its best light.
To wit, what if I had done what I was supposed to be doing in the first two weeks of February, rather than fooling around with a Macintosh? Or, what if I had not been given a Macintosh II to play around with? Where was the serious evaluation of our alternatives with regard to the Macintosh before committing to a multi-year development effort? Where were the trade-offs weighed among that project and numerous other claims on our development resources? Why, if it wasn't a good idea to port AutoCAD when it wasn't thought possible, did it become a good idea when I proved it was possible after all?
As of this date, I do not believe that anybody within Autodesk has a
firm grasp on the constitution of the next release of AutoCAD. The
only firm statement is that it will not run in 640K, though what it
will run under on 16 bit platforms seems presently up in the
air.
One long meeting was held which resulted in an enormous wish-list of
disparate features, but little or no winnowing or aggregation of that
list into concrete implementation proposals has been done to my
knowledge.
To date, no implementation of Release 11 is underway, scheduled, or contemplated. I think we've grown to the point that we can't afford to develop our mainstream product in the kind of cycle that we did in the past. Typically development of an AutoCAD release has focused around one or a small group of central features. Development work would start on these features, with a small number of senior developers working on them. As development progressed, other features would be contributed by those developers or others, often chosen by shooting targets of opportunity off the wish list while making other changes in related areas of the program. As a release date came into focus, usually aimed at a major trade show, Duff would focus on documentation while other developers would devote their efforts almost exclusively to testing and fixing bugs generated by the in-house QA and beta testing process. The effort would reach a crescendo at the release date, with a coda devoted to getting all the other hardware platforms shipped. A period of exhaustion would ensue, followed by gearing-up for the next release. This cycle describes the development of Release 10 to date just as well as it does Version 1.4.
This is how most small companies develop software, and it permits efficient utilisation of limited manpower, minimisation of management overhead, and eases the always-difficult task of product configuration management. The question is whether a company in our position, facing the competition we do, can afford to develop our product in a manner that spends less than half the available time actually enhancing the capabilities of our product. I am sure that Cadkey and Versacad do their development the same way we do, but I seriously doubt that our mainframe colleagues at IBM, Intergraph, and Prime engage in this kind of half-wave development (on the other hand, maybe I'm wrong, but in any case we're the ones playing catch-up, and we can ill-afford to waste any time).
We now have more than 50 people in our software development
department, not counting those in other departments who are dedicated
to the process of getting new releases of AutoCAD out the door.
Should we not move to concurrent development of AutoCAD while
stabilising a release for shipment? Yes, this makes source code
control, project management, resource allocation, personnel
management, and everything else far more difficult. But doesn't
maintaining the technological leadership of a product that's bringing
in 100 million dollars a year justify doing some difficult
things?
This product line, which we acquired from Archsoft and have been steadily expanding our commitment to ever since, including acquiring a second product from them and then reimplementing it as well, is now seen, despite market share leadership, as falling behind the market in both functionality and performance terms. Why should it? This is a product which has generated revenue in excess of $100,000 per month for each of the last 18 months, and has recently contributed sales in the $200,000 per month range. We have an entire sub-department dedicated to development and maintenance of this product line with at least five people exclusively assigned to this product. This development team exceeds in size that devoted to AutoCAD during the period when its sales were comparable, a time during which AutoCAD clearly established itself as the technology leader in its market.
If the people working on the AEC product line are not the right
people, why have they not been replaced with the right people? If
AutoCAD AEC cannot deliver better performance without modifications to
AutoCAD, why have these modifications not been requested, designed,
and implemented? If we have achieved market leadership with this
product but now believe it impossible to maintain, why are setting the
same group that turned in that performance to the task of creating an
“infrastructure” product which we now believe central to
competing
with Intergraph in the AEC market?
AutoSketch was designed to give Autodesk an entry in the low-cost drawing market, both in the hope of its becoming a successful product in its own right, and to protect against erosion of the low end of the AutoCAD market by competitors who could expand from such a foothold by upgrading their products (as Generic CADD has done, precisely as we predicted and feared). The product was previewed at the first AutoCAD Expo in 1986 and shipped in November of that year. Development of the product through shipment consumed approximately one man-year, involving senior development staff exclusively. Following its shipment, the product was essentially ignored by Autodesk's marketing and sales effort as well as the development group until the establishment of the AutoSketch #1 Team in 1988. Recently some technical resources have been expended on the product, initially to create versions for hardware bundling deals and the PS/2, and now to add some user-requested features to the product.
AutoSketch is evaluated in the Marketing/Sales plan as “falling behind the fast moving market of Low-End CAD and Graphics software”. No wonder—it's remarkable that a product on which no serious work has been done in two years is a contender at all; the fact that we've managed to sell 70,000 units of a static product is truly remarkable and a credit to those who made it happen. The reason given for the abandonment of AutoSketch by the development group is “Technical resources”. I disagree—its abandonment is the consequence of priorities being placed elsewhere. AutoSketch is a simple program to learn and work on—I find it hardly credible that if development of AutoSketch had been set as a clear priority for the technical department and the management of that department had acted to obtain and assign resources to the product, twenty-four months would have passed with no action—months during which numerous development personnel were recruited and put to work on AutoCAD, with its much larger and steeper learning curve. AutoSketch has generated revenues on the order of $50,000 per month throughout FY 1988 and 1989 to date, with several peaks near $100,000. Yet AutoSketch has been assigned little or no development resources while AEC, with sales only twice that, has merited an entire subdepartment, dedicated promotion, etc. This is not a resource constraint; it is lack of priority, focus, and follow-through.
The
product strategy for AutoSketch includes a plan to include the
“Rube” constraint manager in the product to provide a unique
point of distinction in the market, make it attractive to a new set of
users (including those with AutoCAD), and possibly move the product
up-market in price and perception. Yet the technology group who
prototyped Rube ceased work on integrating it into AutoSketch over a
month ago because they were unable to obtain any direction, commitment
of resources, or plan of integration from the software development
group.
AutoShade, which started out as a simple interface to rendering software to be provided by Visual Engineering, and ended as an in-house product which consumed on the order of a man-year of senior development manpower, was shipped in September 1987 to provide a shaded rendering capability to AutoCAD users. At the time of its introduction, it was the first rendering product for AutoCAD models, and having sold more than 5,000 units to date, it is clearly the market leader.
After the shipment of the product, it was abandoned by the software development department. Until recently, when one developer on his own initiative ceased work on AutoCAD to enhance AutoShade, essentially no resources were assigned to enhance the product to capitalise on its head start and strong sales, which have ranged from $30,000 to $90,000 per month since introduction of the product. All of the weaknesses cited in the Marketing/Sales Plan except for its dependence of 3D in AutoCAD, an inherent weakness of any shaded rendering product, and the fact that it is separate from AutoCAD (an opportunity for us in the future which is not available to any competitor), are purely consequences of the abandonment of the ongoing development of the product.
In a speech at the InfoCorp Silverado conference in March 1986, I said
that “user interface is a distribution
issue”. In other
words, the economic viability of a low-cost product sold through
retail channels without extensive support depends on that product
being accessible to its potential customers without extensive
training or handholding. One reason that AutoCAD was able to fend off
assaults from PC versions of mainframe CAD software is that users were
able to draw with AutoCAD without spending the time a mainframe CAD
operator would invest to learn his system.
AutoCAD's user interface wasn't all that great in 1986, but it was better than most of the competition. Since that time, we have gotten much worse while our competition has been improving rapidly. Today I believe that no commercial software product with comparable installed base and revenues has a user interface remotely as bad as AutoCAD's, that the situation is degrading rapidly and spreading to our other products, and that the wages of our inattention to what should be at the heart of the design of any interactive tool are now coming due in the form of lengthy test time, unreliable applications, expensive training requirements, and rising product support costs.
Lack of vision, the absence of clear design, inattention to
developments in competitive products, failure to apply reasonable
engineering judgement to counter the demands of a QA department run
amok in fields of casuistry, and general abandonment of the user
interface to whatever seems expedient to developers as code is
written, has resulted in an almost inconceivably wordy, obscure,
error-prone, and virtually impossible-to-document input language which
makes the CADDS 4 commands we used to ridicule elegant by comparison.
It is ironic that a company whose staff ridicules products like
and EMACS as “suitable only for programmers” is engaged in selling
an application whose command language makes either seem a paragon of
clarity and generality.
While AutoCAD's command language was an object of neglect, computer vendors were rapidly raising the stakes by attempting to make the user interface part of their operating systems. It appears increasingly probable that, in order to compete in the future on multiple hardware platforms, an application like AutoCAD must become able to conform to multiple different user interface mechanisms while somehow maintaining application and database compatibility across platforms. There has been general acknowledgement for over a year of the seriousness of this problem and how important finding a solution is to Autodesk's future. During that time, no resources have been allocated to solving it within the software development department—the problem has been left to me to solve in whatever time I make available to work on it, with whatever energy I can spare from other tasks.
Our development and QA staff seems increasingly consumed in debates
over arcana about which nobody outside Autodesk seems to care as
shipment deadlines slide past, while our competitors are creating and
delivering products which are making intuitive concepts that Autodesk
seems to lose grasp of in a lake of wordy commands, and a sea of error
messages whose aggregate size exceeds the total size of some Macintosh
applications. If you don't know what I'm talking about, or think this
is some of the hyperbole often attributed to me, I suggest you
schedule, back to back, a two hour demo in which a robot arm is
constructed with AutoCAD, and a 15 minute demo in which the same task
is done with Swivel 3D, a new modeling product for the Macintosh.
Swivel 3D was originally developed to explore solid model interaction
with the VPL glove, a user interface modality which seems to elicit
laughter from the majority of Autodesk personnel, notwithstanding its
being considered one of the most promising approaches to 3D
manipulation by the user interface group at NASA Ames and having been
the subject of the cover of Scientific American in October
1987..
This has not been a pleasant paper to write. Recounting these observations has opened a large collection of incompletely-healed wounds; anticipating the reaction of those who read these opinions is unpleasant to one who values placidity and amity as much as I do; and making the recommendations that follow mean in large part consigning many of the idealistic goals I had for software development when we organised this company to the dumpster.
But failing to come to terms with what I believe are the facts, and choosing not to act to remedy a situation I believe already dire and rapidly moving beyond hope of salvation, will sacrifice much more than some six year old hopes and dreams and cause far more anguish than some lost friendships and working relationships. If we allow AutoCAD to lose its technological leadership, then I believe it is inevitable, sooner or later, that its market leadership will also be forfeit. If we allow competitors to count on our abandonment of every new product entry shortly after shipment, we are expending our development resources merely to produce prototypes for our competitors to use against us. If our product development does not meet the standards expected from an industry leader, in volume, scope, imagination, quality, and timeliness, then any attempts we make to compete with established industry leaders on their own turf, workstations and major accounts, are foredoomed.
If we do not act rapidly to totally professionalise the technological sector of our business, from senior management, to product definition, to project management, to quality, then we put at risk all we have worked for so long and hard. For years we have been furiously working to catch up with the big guys, and our limited resources have made many of our decisions for us. This allowed us to adopt and survive with a passive, reactive style of management of our development department. This mode of operation is not only inappropriate in a company with a development staff of 50 people and a bank balance of $100 million, it is a prescription for disaster when our company attempts, as we must, to pull out from the pack and extend our leadership position in PC CAD to the CAD market as a whole. We must make these changes even as we acknowledge that they will make the software development department less attractive to entrepreneurially-oriented self-starters, including myself.
The issue here is not a technical department issue; it is the future of our company. The evidence that something is seriously wrong in the software development side of our business has been apparent to me for months, and increasingly people have been coming to me without prompting to share their worries on the subject. This is a problem which imperils our company at least as much as earlier crises in marketing and sales, manufacturing, and accounting. We met those crises head-on, fixed them, and moved on to greater successes. We must not shrink from this one.
|
|