Proposals

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.