|
|
The March, 1983 meeting saw Autodesk rapidly evolving toward an operating company focused on the development and promotion of its hit product, AutoCAD. No regular minutes from the meeting exist—only Dan Drake's notes on what people agreed to do. Those tasks speak eloquently to the direction of the company.
The attached “Software Control Policies” was the first attempt to come to terms with the reality of quality control and effective product management of what was rapidly becoming a mass market product.
We've found several times that people come away from monthly general meetings with different ideas of who has volunteered to do what. We can't afford to discover these disagreements a month later at the next meeting; and the minutes, even if they come out on time, don't cover these matters conspicuously if at all.
This is an attempt to list all the little tasks that were allocated at the last meeting. It doesn't claim to be definitive, but it gives you something to disagree with, preferably to the relevant project manager, if you find yourself listed for the wrong task.
1. Odd Job List
Dan Drake will put out this odd job list on the Tuesday afternoon or Wednesday morning after each general meeting, if it seems to be doing any good.
2. Hewlett-Packard Contacts
Duff Kurland and Jack Stuppin will pursue contacts at HP to get us in touch with their plotter people. Dan Drake will do the same through GDL.
3. IGES
Duff Kurland will try to get the Interim Graphics Exchange Standard from NBS.
4. Computer Faire Setup
Dave Kalish, Mauri Laitinen, and Dan Drake will set up the booth on Thursday, March 17.
5. Computer Faire Co-ordination
Roxie Walker will publish a schedule of work assignments for the Faire. She will also set up the mechanisms for selling things and taking orders.
6. Ethernet Links
Dave Kalish will look into any plans that Apple and 3COM may have for supporting the Xerox protocol on Ethernet; we may decide to write such software if bigger people aren't already doing it.
7. Applescreen
Dave Kalish will get a 300 baud modem and get Autoscreen running on the Apple Softcard.
8. Burning the Boats
Everyone in the company who hasn't done it already will send Jack Stuppin a letter giving the conditions under which he's willing to go to work full-time for ADI: the earliest time possible, the minimum subsistence pay, confidence in ADI's continued cash flow, or whatever.
(This is a draft of a draft, on which I'm soliciting suggestions and arguments. In particular, it would be nice to get beta testing done without a six-week delay. Does anyone think I'm too paranoid about beta test?)
Now that ADI is beginning to get substantial sales, we need to face some of the business questions that can trip us up (unwise commitments, continual vacillation on decisions, etc.). Here are some of my ideas on policies that might save us some grief and indecision; they're inspired by thinking about AutoCAD-86, but it seems to me that they apply to any software.
First I'll give some of the motivations, then a list of ideas that I'd like to see agreed on.
AutoCAD is (subject to a percentage royalty) the exclusive property of Autodesk, Inc. Those of us who wear two hats in order to make a living while building the corporation must keep this clearly in mind while wearing the consultant or dealer hat.
We've been determined from the first to uphold the highest standards of quality and reliability. Lacking capital and sufficient marketing staff, we have no other unique edge on the rest of the world.
There are only two or three people in the company with the experience of making a product that goes out into unknown places in the real world (as distinct from software for a service operation). I don't think we have anyone who has sent out a program in hundreds or thousands of copies as we plan to do. In this environment a little bug in a program can mean a little incremental update for vast numbers of customers, which will feel to us like a GM product recall.
Our testing procedures so far have not been rigorous enough. In the future, we need real, bona fide, beta testing. At best, this will have an effect on our product development time that will seem little short of disastrous; we need to make realistic plans that will keep us in the best case.
One of our most important plans is to put the software on every machine that will have any substantial sales, so that manufacturers will in effect have an investment in us and won't look promising to potential competitors. It's important to remember why we're doing this, so that we don't get off track. If a dealer lends us equipment for a conversion, we don't do the job as a friendly gesture, a speculation on selling a couple of dozen more copies, or even a service for a fee; we do it because a working version of the program may give us a shortcut through the manufacturer's bureaucracy, or at worst produce vast numbers of sales through many dealers.
Meanwhile, every conversion that's released for sale increases our support burden, and every commitment to do a conversion puts our credibility on the line.
It's important for everyone to know who makes what decisions. It's not especially important to distinguish between the board of directors and the top management, since they're pretty much the same people; but we need a feel for what the board does and what it lets someone else worry about. I've tried to outline the level at which various decisions should be made.
Any technical work that any Autodesk person does on AutoCAD is the property of Autodesk, Inc. The person doing such work is wearing an Autodesk hat and will be compensated by Autodesk's normal procedures.
All decisions on selling the product of such labor (e.g., whether, when, where, and how) belong to the company. Making such decisions is a property right: the “first refusal” provision of the employee agreement does not apply, insofar as the work is based on privileged access to Autodesk's intellectual property.
If the company decides to distribute a piece of work, it will sell to any qualified distributor or dealer who wants it. The only exception might be an exclusive distributorship agreement negotiated at arm's length; such decisions would never be delegated to the low level of a product manager or even a marketing manager.
When policy is to put software on lots of equipment, anyone involved with the product can and should talk to any interested supplier. After the first conversations, the company may decide to make a conversion for evaluation by the manufacturer. No one but the product manager (possibly under orders from above) can make this commitment, and no one should hint otherwise. Our credibility is on the line here.
When we've converted something, the supplier gets an evaluation copy. This will serve as a basis for negotiations on the possible distribution of the product. It must be absolutely clear to the supplier that we are in no way committed ever to release anything to the public. The marketing decision belongs to the company; what this means is that the marketing manager makes the decision with the agreement of the product manager, who will have to provide support.
Obviously, no one will pay us an engineering fee for a conversion without a commitment that we'll let him sell the product. The last paragraph doesn't apply if such a case ever arises.
It is standard policy that we will not support any piece of hardware unless we have a piece of that hardware on indefinite loan. Of course, we will never make a change that introduces a bug into something that worked before, any more than Jimmy Carter would ever lie to you; but we can't prove that a problem isn't our fault unless we can reproduce it first. Besides, as a practical matter, our good repute requires us to be able to reproduce problems that a user reports, and provide a correction, even though we are blameless.
People who are working on new features will be left alone as much as possible, because breaking their concentration squanders the only resource that we have in quantity. Before calling an implementor, consider whether someone else, such as a product manager or a salesman, could do as well. As for the release of a programmer's phone number to anyone outside the company, the general rule is simple: no. The handling of exceptions will be up to product managers. In the ACAD-86 game, the product manager is the only person whose phone number can be handed out without his prior explicit consent.
No change in software, however small, can be released for sale or even for beta test without clearance from the product manager. Any manager who does not constitute the entire project staff must work out procedures for source code control and distribute them in writing. (This will raise problems when someone overseas is making versions that change nothing but the language in which the messages are written.)
In AutoCAD-86, for example, there will be a clear distinction between a core section and device controllers. One programmer will have primary responsibility for the core code and will do integration and testing of any changes worked out by other people. When a new version is ready, it will be distributed in source and relocatable form to the various people in charge of device drivers, who will integrate their drivers with the supplied relocatable and do thorough testing. If this exposes a need for changes in the core source, the countdown stops while the change is worked out, integrated, and distributed to everyone for the next iteration.
Product managers must also work out plans for beta testing. We need some good ideas here, and we need to live up to them. Fortunately, the iterative integration process in the last paragraph can be overlapped to some extent with beta test.
It appears that the features freeze will be weeks before the release date. It will take a good deal of self discipline to avoid diddling the code as the testing cycle drags on.
The bulk of documentation work should be done, as we all know, at the beginning of a new development, not at the end. Whether we can afford to do this really right is an open question. In any case, the document will not be a last-minute panic project. The documenter will estimate how long the job is to take; the project will then be scheduled so that a draft will be ready when beta test begins. For final proofing there will be a mock camera-ready version two weeks before the release date.
Several people attempted to use early releases of AutoCAD to make this beautiful drawing of the shuttle that graced our sample drawings disc for so long and appears in so many advertisements of display hardware for AutoCAD. This version, the one we finally used, was drawn by Sean O'Donnell.
|
|