Next Up Previous Contents Index
Next: Ten Years After Up: The Autodesk File Previous: AutoCAD LT Questions



Ever since, seeking venture capital in 1983, we wrote the first formal Autodesk ``business plan,'' I'd been bothered by how blithely such documents predict things which I know from personal experience to be utterly incalculable. To run a business, one certainly needs forecasts, budgets, and plans, but making a spreadsheet for a product or company that doesn't yet exist showing revenue from sales to customers who have yet to be identified is just a waste of time, especially given how many uncontrollable factors can affect the outcome.

It amazes me that, at the very moment when central planning of national economies is thoroughly discredited and being abandoned in favour of market systems, the management culture in the West seems increasing gripped in a dirigiste mindset right out of mid-1920's GOSPLAN--leaders of businesses who proclaim the market as supreme view the market as something entirely external to their carefully-planned and tightly-controlled enterprises. They would shudder in horror at the thought of allowing the messy, unpredictable forces of the market into their own operations--how chaotic!

I use the word ``evolution'' a lot because I believe it's central to understanding how markets really work, how technologies emerge and mature, and how actual products are developed in the real world. In the early days of Autodesk, I didn't even try to guess which product would succeed--I knew I wouldn't have a hope of making such a prediction accurately. But I was pretty confident we could bat .200--that at least one out of five products we chose would succeed in the market. Then, and only then, would we focus our efforts upon the winner.

Think of it as evolution in action. We, as product developers, are creating new species, almost as blindly as the shuffling of genes, with the market---our customers--performing the winnowing process of selection. As in biology, there's no way to know how well something will work without trying it. Yet once it gets out there, you learn pretty quickly whether it was a good idea or just plain dumb.

Unlike Darwinian evolution, where selection is entirely decoupled from the mechanism of variation, products evolve in a Lamarckian manner. Training a dog to drive a car doesn't make its pups into better chauffeurs, but when a bunch of customers tell you ``we want a little window in the upper left of the screen that shows the whole drawing with a little box for where we're zoomed into,'' the developers say, ``Yes sir!'' run off and hack the genome to squeeze the gimmick in, and hand it back. ``Will you be needing anything else, now?''

That's why it's ever so important to get a product into the field early and to have a rapid and responsive development and upgrade program. The first product in a category benefits from the feedback of customers and can quickly begin to converge toward meeting their requirements, often growing in directions not remotely anticipated in the original design. This is how AutoCAD developed--it is how every product which is successful in the long term develops--and it explains why large, mature products tend to be messy and complicated, because they have accreted, over the years, a large number of features, each requested by and valuable to, a set of customers. It is when the process of co-evolution of a product with its customers and the underlying technology slows down or stops that the product becomes vulnerable to competition. Only when a customer ceases to believe that the product he already owns will meet his needs in the future does he goes shopping for a replacement.

All this seems so obvious to me that I rarely bother trying to explain it, and yet the process by which products are proposed and developed in many organisations, including Autodesk, seems diametrically opposed to this evolutionary philosophy. Instead, we do market research (asking people what they think about something that does not exist) in order to make a detailed design, forecast market acceptance in advance, then build the product all-up to be perfect from the start.

This isn't how I learned to do engineering, and I don't think it works any better in business. The only way I know to find out what real customers want is to sell them something and then listen when they tell you what's wrong with it, and what's right with it. This process, of course, doesn't produce all the nice viewgraphs and charts and spreadsheets which are required in modern business, so it must therefore be bad.

After reviewing a number of business plans and product proposals in 1993, all of which envisioned a totally planned-from-the-start design and development process, I wrote the following piece.

Creationist Software Development

by John Walker -- November 5, 1993

I think there's a ``meta meta'' issue that underlies the whole concept of concurrent engineering and design for manufacturing which derives from a bogus idea of how products are created which has been running rampant primarily in the U.S. for about 15 years. As far as I can tell, it is a new phenomenon, but I can't identify its intellectual roots. I know that when I try to talk about it with many people, even in conjunction with software design, I often feel like I'm explaining quantum field theory to a cat.

What I'm talking about is the ``Cult of Design''--the whole bogus idea that with the proper research, our powerful intellect, marshaled by innovative management processes, and, oh yes, breakthrough design, modeling, and simulation tools, we can create, ab initio, products which can be mass manufactured from scratch at precisely predicted cost and quality levels, which are accepted immediately by the identified customers, and return the expected revenue to their developers.

What a pile of crap.

It took me quite a while to even appreciate the extent to which this cult of design had taken root--it really hit home when I   encountered the Xerox PARC types involved with Xanadu who actually believed (and still believe today, after 8 years of failure) that they can design, in its entirety, a system which can store all the information in every form, present and future, for quadrillions of individuals over billions of years. I am not making this up--ask 'em the question directly, and that's what they'll say.

Then it slowly dawned on me that it wasn't just the Mambo     Chicken[Footnote] crowd who had hyper-warped into the techno-hubris zone--it was everybody, except for a few crusty old-timers like me.

I mean, when I learned engineering, the entire message was that engineering was an imprecise, underconstrained process, where there were always things you couldn't calculate and often you just had to try. Certainly, you should quantify and calculate everything you could--that's what distinguishes engineering from tinkering--but the real world is full of intractable problems that nobody has a clue how to model. Computational fluid dynamics is probably decades if not centuries away from being able to model the ignition transient in a garden-variety liquid rocket engine. So everybody in the game just figures on making and blowing up a couple dozen before they find a pattern of holes in the injector that ``seems to work almost all of the time.''

And when you get even a little distance from things where the physical principles are at least known, such as economics, customer preferences, or competition in the marketplace, it's a situation where there isn't a shred of a credible theory on which to base your calculations.

And yet lots of people seem to believe, for some reason, that they can predict such things.

I think it's related, in some way, to the obsession, especially in the U.S. that everything needs to be entirely risk-free and that any failure of any kind is unacceptable. Therefore, we must calculate everything in advance so that we succeed perfectly the very first time and continue to succeed precisely as predicted by our calculations.

  This, I believe, is how one manages to spend US$10 billion and ten years ``designing'' a space station for which no hardware has yet been fabricated and for which, at the present moment, no concrete design yet exists. One can probably spend US$10 trillion on such an effort and produce nothing because the effort is as impossible as factoring a trillion digit number; one can certainly build a space station, but only by taking lots of small steps in which you make mistakes, come to understand what the real problems are and how to fix them, and build up enough confidence so that when you do finally write the check for the mondo starbase, you have a reasonable expectation that it will work pretty much as you expect.[Footnote]

And while NASA is a master of this, you need only look at General Motors spending US$7 billion and 8 years to ``reinvent the factory,'' and finally managing to make, in 1991, poor copies of 1985 Toyotas with engines that catch on fire.

Closer to home, folks are entirely confident that they can determine precisely what features are required in a new product to meet the needs of customers in a wide variety of industries and environments, calculate how long it will take to create such a product, determine its price point, and predict in advance how many copies will be sold and how much revenue will be returned. In fact, without a ``business plan'' which claims to do this, no product development effort will obtain funding.

When this process totally fails, and it always does, that doesn't seem to weaken the belief in a ``design process'' which, in reality, is as bogus as astrology. It's always a bad manager, problems with tools, etc.--precisely the unpredictable factors which make a priori design impossible in the first place.

Absolutely the only way I know to succeed with an innovative product is to throw something together quickly, push it out the door, persuade some lunatic early-adopters to start using it, and then rapidly evolve it on a quick turnaround cycle based on market acceptance and driven by a wish list from actual users.

Every successful product I have been involved with, either as a developer or as a user, seems to have followed this path. I think that when people beat up Microsoft for shipping shoddy early releases, they just don't recognise that early releases are shoddy inherently, because they haven't had a chance to evolve based on customer requirements. (Of course some are shoddy due to plain old bugs that should have been found during development; that is inexcusable.)

That is certainly the development strategy Parametric has followed with Pro Engineer, and I would put the probability of beating that product with a ``right the first time better solution'' at exactly zero.

Study it forever and you'll still wonder. Fly it once and you'll know.

--Henry Spencer

...I have not failed. I've just found 10,000 ways that won't work.

--Thomas Edison

We are the products of editing, rather than authorship.

--George Wald

I've pretty much given up trying to explain this old-time engineering philosophy to people--they just don't seem to get it. So these days I just try to avoid projects that work that way and concentrate on what is disdained as ``maintenance programming'' or ``hacking'' of the kind that produced AutoCAD.

In June 1991 I started to write a screed titled, ``The Evolutionary Paradigm--Engineering, Management, Markets, and Choice'' which would attempt to explain all of this so clearly that it might have a chance at turning the product development culture at Autodesk into which I believed were more productive modes. I really think that this design cult is nothing more than a branch of creationism which thinks its members are so omniscient that they have no need for market-driven evolution to perfect their efforts. Evolution is messy, unpredictable, and utterly unmanageable. Its sole advantage is that it works.

After writing a few paragraphs, I gave up and went back to work on AutoCAD--I quickly realised how hopeless it was to convey these concepts when I had found myself incapable, in person, of explaining them to people I knew to be smarter than I am.

Next Up Previous Contents Index
Next: Ten Years After Up: The Autodesk File Previous: AutoCAD LT Questions

Editor: John Walker