Evan on Engineering Software

I just finished reading Dreaming in Code, a book which chronicles the first years of Chandler, a major software development project that could have been the apocryphal "next big thing."

Mitch Kapor, the co-founder of Lotus Development Corp, designed the first "killer app" for the then-new IBM PC in 1982: Lotus 123. Kapor’s work has had a deep and positive effect on the computer industry. Among other things, he co-founded the Electronic Frontier Foundation, and has served as the chairman of the Mozilla Foundation since its inception.

In 2001, Kapor founded the Open Source Applications Foundation, and started the Chandler project, to create a new-generation killer app: an "interpersonal" information manager that could adapt to users' changing needs.

Now, saying that something can adapt to users' changing needs may seem to be a rather nebulous statement—but it implies much. Most personal information managers (PIMs) draw strict distinctions between things such as email, calendar, and to-do items. This is not because users desire such strict distinctions, but rather because it is inherently difficult to make software that can deal with groups of distinct things abstractly.

In Dreaming in Code, author Scott Rosenberg follows the genesis of Chandler for three years, from Kapor's initial vision, to the shipping of version 0.6.

Despite having a team made up of brilliant developers, Chandler has, by most measures, been a tragic failure.  Yet, Rosenberg never quite connects the dots to explain where Chandler went wrong. It’s possible that he was close enough to the project that he couldn't see that Chandler was doomed from the start.

Mitch Kapor is sometimes called the father of Lotus 123, but it’s fairer to say that its real father was Jonathan Sacks, Kapor’s partner in Lotus. Kapor designed how Lotus 123 would work, but it was Sachs who actually wrote the program—in assembly language (an incredibly difficult feat that puts him in the company of a very few legendary programmers, including the CAD industry's Mike Riddle, who single-handedly wrote FastCAD in assembly language.)

CRN magazine wrote about Lotus 123:

Kapor and Sachs spent 10 months developing the project. The key, Sachs said, was that 1-2-3 was based on an existing prototype he and Kapor had previously created. Instead of setting out with a grand concept to include a boatload of features, Sachs and Kapor simply added features to a core product. At every stage of development, a working tool existed. As Kapor and Sachs added feature after feature, they distinguished 1-2-3 from any other spreadsheet, including VisiCalc.

"It wasn't like we sat down and designed everything and then built it. There was no point where we sat in a room and drew this thing on a whiteboard that said: spreadsheet, graphing, database, macro language," Sachs said.

What a contrast.  Chandler had no working prototype. It was all grand concept with no substance—a drawing on a whiteboard that said "email, contacts, and calendar," yet no plan of how to make it real, other than hiring two dozen programmers, and hoping for a miracle.

Rosenberg tries to explain the failure of Chandler (without actually calling it a failure) by drawing on the writings of Frederick Brooks, Donald Knuth, and Alan Kay—each of whom has won the ACM Turing award (the highest technical honor in the computer industry,) and each of whom, many years ago, helped to explain why software projects so often fail.

Too bad Rosenberg misses the irony: Lotus 123 was a spectacular success largely because Sachs understood (whether implicitly or explicitly) the lessons of Brooks, Knuth, and Kay. Chandler has become a spectacular disappointment largely because Kapor either didn’t understand those lessons, or thought they no longer applied.