Good stories get bigger with age. The fish that got away or the size of any remembered body part only gets larger with the retelling, never smaller. But what if the story is not just good, but great? Then it gains mythic -- Elvisian -- proportions. While always entertaining, this memory inflation isn't accurate, and it sometimes causes problems.

Last week in the Jose Mercury News was a wonderful story by Jodi Mardesich. It was about Star Trek, the codename for a secret Apple Computer project in 1992 to get the MacOS running on Intel PCs and maybe, just maybe, take a bite out of Microsoft at the same time.

The story came to light because of the expiration of five-year nondisclosure agreements and a desire on the part of the Apple engineers to relive their secret glory. But it wasn't just Apple engineers -- four of the 18 developers came from Novell. And the computers they used were donated by Intel.

Jodi's story can stand by itself (see the "I like" links), but the short version is that these Apple and Novell programmers set up shop across the street from Intel in the summer of 1992 with the goal of having the MacOS running on a 486 by Halloween. They made their deadline.

Apple was impressed, Novell was impressed, and the technical team was given bonuses and a company-paid Mexican holiday. But somehow the operating system just never appeared.

Jodi -- a great reporter and a friend of mine -- attributes this failure of Star Trek to go where no Mac had gone before to Apple internal politics. One of the top Apple execs pushing the project, Roger Heinen, was lured to Microsoft about that time. And Apple CEO John Sculley -- another proponent -- left shortly after. With Star Trek's corporate champions gone and facing the technical challenge of also migrating to the PowerPC, Apple just let the project die.

It's a great story and has just enough myth-making hooks to grow in future retellings. "Was Roger Heinen lured to Microsoft just to kill Star Trek?" the conspiracy theorists will quiz, raising their eyebrows. Did Sculley leave mysteriously, too? Was this Apple's big chance to steal market leadership from Microsoft three full years before Windows 95?

No.

Before this story gets out of hand and the failure of Star Trek becomes attributed to Microsoft death squads, let's get some perspective. What the Apple and Novell engineers demonstrated on Halloween, 1992, wasn't an operating system. It was a demo. It looked like real code, acted like real code, but was really a digital minefield. Comdex secret demo suites are built from such programming.

Star Trek was nowhere near being a shippable product, unless of course you apply the old Novell rule that "if it compiles, we ship."

And while the departure of Heinen and Sculley may have played roles in Star Trek's failure. It wasn't just political infighting that caused the problem. For some reason, Star Trek was intended to be source-level compatible, but NOT binary compatible with the regular MacOS. This meant that Macintosh applications wouldn't work out of the box on Intel machines, but would have to be recompiled for the new processor. Every Macintosh developer would have to write (and box and ship and accept returns of) separate 68K/PowerPC and Intel versions of each application. Developers don't like this.

The Apple engineers, excited about their proposed new product, greatly underestimated the amount of rework that independent software vendors would have to do. The ISVs that were approached to rewrite their applications for Star Trek were all pretty skeptical about the amount of rewriting that would be needed.

After all, the synthetic CPU that Apple used to emulate the 680X0 processors on their first release of MacOS for PowerPC was a dog, and it didn't even have to do any of the byte swapping that a synthetic CPU for Intel would have to do. Apple had done enough engineering for a proof-of-concept for Star Trek, but that was nothing new. They had built a similar proof-of-concept version of Pink, the Taligent operating system that also never appeared.

Apple's engineers often misunderstood key engineering issues and built houses of cards instead of serious OSes. They did this again last year with Copland, yet a third failed operating system.

Although a lot of Mac fans have cited the switch from 680X0 to PowerPC as a tremendous engineering accomplishment for Apple, they went about it in a way that left Apple still stuck on a single CPU, which is where they were when they started. They just switched chips. Very bad. Doing it the right way would have given Apple what the BeOS is today.

What's really ironic in this story of secret missions gone sour is that a binary-compatible version of the MacOS for Intel processors is already on the market and has been for several years. Executor 2.0 (soon to be 2.1), from my friends at ARDI in Albuquerque, New Mexico, will run most out-of-the-box Macintosh applications on a 486 or Pentium PC and often do it faster than on a PowerPC. Executor looks a little different than the regular MacOS because Apple owns the Macintosh look and feel. And Apple sues.

ARDI is never more than half a dozen guys and gals whose corporate holidays may include Mexican food, but it's at the restaurant down the street. Without any access to Apple technology or intellectual property, they completely reverse-engineered the MacOS -- not just for Intel chips, but also for the PowerPC (a synthetic CPU to compete with Apple's -- ARDI's was much faster) and DEC Alpha. And this from a group of programmers who periodically play in Las Vegas poker tournaments to help fund their company.

In our love for corporate infighting and intrigue, it's easy to forget that the perfect size for a development team is one programmer, that little companies can move faster than big ones, and that the ideal fuel for producing code is not money, but beer.

Still, there are some things a big company can do that a small band of programmers could never hope to accomplish. This was best shown to me this week by reader Brian P. McLean, who points out that according to his Microsoft Outlook 97 scheduling/datebook application, Thanksgiving falls this year on Wednesday, November 26.

Thanksgiving has always fallen on Thursday before. Wednesday may be an improvement. I don't know.