Pretty image
When we were young(er), we used whatever tools we had for solving our programming problems. Mike reflects on the early days of Macintosh programming, naive entrepreneurship, and tables with Thom Hogan.

In the earliest days of Macintosh programming, I was part of a garage startup called Macreations. The company eventually produced a product and made money, no thanks to me. Here’s how I remember that experience.

Time After Time

When Apple introduced the Macintosh back in 1984, two friends and I started brainstorming about how we could develop software for it. Thom Hogan, Roger Chapman, and I sat in Thom’s garage/office and sketched out plans for a game we called Time After Time. I’m really hazy on the details, but I seem to recall that it was story-based and that you could go back in time and change history. Something like that. It was going to be rich in historical detail and built on a nifty artificial intelligence engine that we would create.

Thom and Roger took a copy of Apple’s ring-bound developer manual, Inside Macintosh, with them for a weekend in Tahoe. The plan was to spend three solid days getting up to speed on Mac programming, and then come back and jump right into development. They returned bleary-eyed with a “Hello World” application that they seemed inordinately proud of.

But they had reason to be proud, because the learning curve for Mac programming back then was modeled after the face of Half Dome in Yosemite. It was widely repeated that the prerequisite for reading Inside Macintosh was a thorough understanding of Inside Macintosh, and this wasn’t so much a witticism or a zen koan as a straightforward description of the Mac developer experience. Although it may also be a zen koan.

I didn’t need to get up to speed on Mac programming because I was going to be responsible for the supernifty AI engine, which I would develop in whatever language I deemed appropriate. Roger would do the real hardcore programming and Thom would do some of everything, including concept, story development, and running the company.

But then I got a real job, Roger got busy with other things, and there was no time for Time After Time. Thom later teamed with hotshot Mac developer Kurt Matthies, to whom he eventually handed over management of Macreations, and along the way they produced a product called Tycho Table Maker.

Which is what I want to tell you about.

Money on the Table

“Tycho was a result of my doing the PC Programmer’s Sourcebook,” Thom told me recently. That book was nothing but tables, and it was a bear to produce. Thom sought in vain for software to help him create the tables, eventually settling for doing them all in Excel, which “caused all kinds of problems.”

After he finished the book Thom “sat down and designed the product I would have wanted to do that book, hooked up with a Mac programmer,” and created Tycho Table Maker.

“From the beginning Tycho was really a one-shot for me,” Thom said. “It seemed logical to me to complete the product, make some money off it, then sell it. We did a few deals along the way, including a bundling arrangement with Ashton Tate (FullWrite) that actually allowed us to pay back investors and make some money. Right after that deal expired Aldus attempted to buy us. The deal on the table was US$1.5M, and since we had paid off the investors, it was going to be pretty much the three primaries (me and two programmers) who benefited.”

But the Aldus deal fell through, and that’s really what I want to tell you about, because of how it relates to programming today.

Just Not Your Type

Thom called Tycho “middleware.” I don’t know if he coined the term, but what he meant by it was this: “the goal was to suck data out of a database, format it as a table, and stick that table into page layout or word processing.” Because Tycho occupied this middle ground, it wasn’t primarily a product to be sold to end users, but one designed to get bundled with a page layout or word processing application. Thus the deal with Ashton-Tate for FullWrite, the later deal with Nisus, and the failed sale to Aldus.

“[W]e were deep in due diligence and [Aldus President Paul] Brainerd wanted the deal done,” Thom said. It was technical problems that scuttled the deal. “[T]hey didn’t have a library for typesetting. [T]here was no way to exactly duplicate the typesetting. We couldn’t call their typesetting, since it was hard-coded and not isolated and no one even knew how it worked! Thus, we couldn’t guarantee that a table within Tycho paged within a PageMaker document would typeset the same way as the main document.” Unlike PageMaker, Tycho was designed to call a typesetting module; it wasn’t hard-coded to any given typesetting method.

As reviewers pointed out at the time, Tycho wasn’t really integrated with FullWrite, it was just bundled with it. Later, when Nisus bought the product, it did get integrated with NisusWriter and is the table component of that product today. But none of these deals, successful or not, went smoothly.

As problematic as it was working together with big companies back then, Thom sees it as even harder today. “Microsoft and Adobe are more unreachable than before. Ditto for the computer companies." Thom works with camera companies these days, and finds them just as unapproachable. “I’m in Japan at the moment,” he emailed me, “and just met with several luminaries at Nikon, but that took an enormous amount of string pulling.”

While Thom is probably right about the difficulties independent developers have in getting attention from the big companies, it seems to me that the kind of problem he faced with Tycho would be approached differently today. The big companies may be unapproachable, but their software isn’t necessarily so. The big companies participate in standards groups and expose their software’s functionality through APIs and generally recognize the value of third-party add-ons.

The world of software development, as Mike Taylor points out in his essay on libraries, is more collaborative than it was in the days when Thom and Kurt developed Tycho. “[T]hat’s both a good and a bad thing,” Thom thinks. “The good is that we have better building blocks to work from now. In the old days we had to build our own blocks,” (feel free to picture here a group of cavemen sitting around a fire, baking bricks with words like “TYPESETTING” and “STYLESHEET” carved in them) “which meant a lot of needless duplication for simple things. The bad is that the building blocks are often too center-of-the-road or limiting.”

Thom’s focus these days is on photography. He defends his opinion on the downside of generic components with an example from photography. “I don’t know of any imaging component that uses precise enough math. Even Adobe’s own modules get them into trouble occasionally (try plugging in a white balance setting of 1 for red, green, and blue for a file and see what happens: the Adobe software doesn’t know what to do with aninteger!) We all had to stop using a true UniWB (1,1,1) and use a nearUniWB (1.0004, 1.0001, 0.9998 for instance).”

Thom admits to missing the days of assembly-language programming and total control of your product. “If the program ran too slow, produced inaccurate results, or wandered off into memory it shouldn’t, at least it was my own fault. Libraries have this habit of doing all those things for you ;~).”

Having made his mark in publishing (InfoWorld editor, dozens of technical books), software development, film and television production, and music, Thom Hogan now spends much of his time photographing the wilds and teaching photography workshops in some of America's most interesting outdoor locales. He also writes books about Nikon cameras. His work can be found here.

Send the author your feedback or discuss the article in the magazine forum.