Comment by mblakele | Hacker News Reader

Comment by mblakele | Hacker News Reader

I came out of this article with a new respect for John Walker of Autodesk. Here's his take on the collision of architecture astronauts and waterfall project planning:

John Walker, Xanadu's most powerful protector, later wrote that during the Autodesk years, the Xanadu team had "hyper-warped into the techno-hubris zone." Walker marveled at the programmers' apparent belief that they could create "in its entirety, a system that can store all the information in every form, present and future, for quadrillions of individuals over billions of years." Rather than push their product into the marketplace quickly, where it could compete, adapt, or die, the Xanadu programmers intended to produce their revolution ab initio.

"When this process fails," wrote Walker in his collection of documents from and about Autodesk, "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."

http://www.fourmilab.ch/autofile/www/chapter2_108.html continues with:

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.

The tools that we shape, will in turn shape us. The trouble is that if you release a project early, the people who use it or participate in it could become used to its current state and fight against any change.

You can see this with Microsoft products. Microsoft has to have its updated products compete with its previous products.

This is also true of Project Xanadu. If we consider the Web as an early form of Xanadu, we can see that it was released prematurely. There are lots of design flaws and over the years band-aides have been applied to them. There are still many people who fight against these band-aides (I'm looking at you IE6 users and corps who force the use of that browser). We're stuck using hacks for what should be easy. People are now used to do things the hard way and using hacks and cannot easily envision a system that doesn't suck.

Worse is Better is about LISP vs. C, but it fits Xanadu vs. WWW.

worse-is-better:

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.

the-right-thing:

First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.

The Web was only half-baked, but it wasn't released prematurely.

Anything actually working was released when only half-baked; perfectionists either never release anything or they release it so late that it never gains any traction against its already-in-use competitors. The first release of anything that is going to succeed is effectively going to be a prototype, whether the inventors intended it to be or not.

Reply on news.ycombinator.com