Would You Buy a $2,000 Software Package From

cottonseedfearnotElectronique - Appareils

7 nov. 2013 (il y a 7 années et 11 mois)

261 vue(s)

Would You Buy a $2,000 Software Package From
These People?

Microcomputer Market in 1982

The microcomputer market was very diverse. There
were many manufacturers making different
hardware and running different operating systems.

Developing hardware required huge capital
investments and was very risky.

The mainframe computer view was that software
was just a sales tool needed to sell hardware. This
was the initial view in the microcomputer industry
as well.

It was becoming clear that views about software
were changing.

The New Business Environment

IBM was about to enter the microcomputer market
with a machine aimed at non
technical consumers.

A software developer who had licensed a simple
spell check to Tandy for their Color Computer was
getting royalties of $100,000 per quarter.

Word processing and spreadsheets had become
viable products independent of hardware sales.

Beginning of Autodesk

In Late 1981 John Walker floated the idea of a new
company, initially called Marin Software Partners,
to a limited group of people. It would attempt to
enter the microcomputer software market.

He had come to realize that his small hardware /
software company, Marinchip Systems did not
have a bright future, even though it had good
hardware and probably the most advanced
collection of software available for any
microcomputer anywhere. The more effort he put
in, the more demanding the business became,
without dramatically increasing revenues.

Startup: Corporate Support

We were self
funded. This was appropriate for the
beginning. After a time, we tried to get outside
funding but nobody would touch us. We struggled
for a number of months. After AutoCAD started
selling, everybody wanted to invest, but by then
we didn’t need the money.

There are companies today that start with limited
funds and work hard to become self funding. It’s
still a viable model.

The Initial Idea

We planned to develop & market applications for
market systems, like CP/M, IBM DOS, and
Unix System III.

We would avoid products requiring specialized

No grandiose systems needing all

We would try a bunch of different programs, and
whatever took off would be what we supported

The Dawn of AutoCAD

Among the products we considered were a Basic
compiler; a C compiler; sort, spell checking,
telescope lens design, diff, and database programs;
and a simple drafting program called Interact.

Interact was created by an acquaintance of Walker
& was written in a home
grown language called

The idea of a drafting program seemed
worthwhile, and work began on MicroCAD.


We renamed Interact MicroCAD, made a royalty
deal with its originator, and tried to port SPL to an
Intel 8080 machine running CP/M. Interact ran
only on a TI9900 system.

A C compiler turned up for 8086 machines, and
PL/I was used for the Z80, so all the SPL code
was thrown out and implemented on new

We had to change the name to AutoCAD when
somebody trademarked MicroCAD before us.

Comdex 1982

In November, 1982, AutoCAD was shown at
Comdex in Las Vegas. It was a big hit.

Growth & its Problems

From the early trade shows, we learned what
people wanted in AutoCAD.

At the same time, marketing was selling the
package to every computer and peripheral maker
they could find.

Support for new features and new hardware
became a serious burden.

The other programs were being cast aside.

Software Engineering Lessons:

Firm, up
front requirements exist in software
engineering texts and in mature products. Our
requirements came from:

basic infrastructure needs

hardware & software limitations

customer requests

the need to support new hardware

It’s not clear that any structured approach to
requirements analysis would have been possible or
would have turned out better.

Need for speed meant minimal requirements

Requirements: Text vs Actual

In general , the high
level requirements as
described in section 5.1 were not used, except for
new feature descriptions.

functional requirements tended to be treated
as design issues.

No design standards, software standards, GUIs
were available or offered any development or
sales advantage.

From experience, we knew that nobody would
read extensive requirements documents; not the
designers and not the people who were asking for
the features.

SE Lessons: Design

Our biggest design constraints came from the
limitations of hardware & software at the time.

Tremendous amounts of time were spent trying
to figure out harware & to debug compilers.

The IBM PC Tech Reference was a godsend.

Initial design used the existing program as a
template. Subsequent design based on our best
guesses about what particular features constituted.

No design methodologies seemed to fit our needs.

SE Lessons: Team Organization

We used the “Texas Ranger” team organization:

A Texas Ranger comes to town and says to the local
sheriff, “I’m here to handle the riot.” The sheriff
says, “but you’re just one Ranger!” He responds,
“Well, there’s just one riot, ain’t there?”

It helps to have brilliant, experienced people.
Every founder had at least 10 years of
programming experience. In general, individuals
worked on single projects or machines or both.

We didn’t hire less experienced programmers for
the first 3 years.

SE Lessons: Planning

None of us were experts in our application field.
This might have been an advantage: we had no
preconceived ideas about what CAD should be.

If we were experts in anything, it was software

At every point, we had too many options and too
little information. There’s still no method that
deals with this problem.

The value of experience, skill, and dumb luck
can’t be underestimated.

SE Lessons: QA

I came on board in 1984 and started software and
physical testing systems. We had serious
problems in both areas.

For mass
market software, both ad
hoc and
planned testing is required.

Regression testing essential

Performance testing essential

No development methods exist that make testing

SE Lessons: Process

We looked at process methods, but never found
canned ones (e.g. CMM) that worked.

Internally developed processes, along with lots of
training and reinforcement worked.

Processes must be implemented by senior people.

Processes are tools, not ends in themselves.

Most sophisticated metrics are worthless. Choose
a few, simply implemented metrics & integrate
them into existing processes. Test & revise.

SE Lessons: Is the Book Wrong?

We pretty much contradict what the book says. So is
it wrong? Not necessarily.

Startups are not mature companies. What’s great
for a startup can be disastrous for an established
company, and vice versa.

Getting a product out is more important
sometimes than having the most robust process. A
reasonable tradeoff may exist between getting the
product right and getting it out the door.

Is the Book Wrong?

Neither we nor our customers knew what we
wanted. More analysis would have been futile.

We had no basis for estimating effort or time. No
model would have helped.

From Here to Maturity

Today, Autodesk develops software according to
more detailed plans, Delphi
based estimates, and
requirements documents. Object models are
developed and test plans are used.

Features are implemented by teams rather than

Most new products are additions to or
enhancements of existing product families.


Startups are extremely demanding. Organizations
are in constant turmoil precisely because they
aren’t mature.

Software engineering methods designed for
mature companies may actually be destructive for
small startup organizations.

Canned processes probably don’t work.

You do what you have with the resources

Get some experience, then start your own