An innovative feature for a PIM: stamping.

Interesting feaure:

Yin explained the latest thinking on items. Most PIM programs required users to decide up front, when they created a new item, what it was: Were you creating a new email? A calendar event? A to-do task? Chandler would instead let you sit down, start typing a note, and decide later what kind of item it was. Like the human body's undifferentiated stem cells, notes would begin life with the potential to grow in different directions. This design aimed to liberate the basic act of entering information into the program from the imprisoning silos. It also made room for Yin's proposed solution to the item mutability problem: The mechanism users would employ to specify the "kind-ness" of an item would be called stamping.

Say you had typed a note —a couple of sentences about a meeting— and then wanted to put the meeting on the calendar. You would stamp the note as an event. Chandler's detail view would add fields that let you specify a date and a time; your generic note was now an event. Later, if you wanted to invite a colleague to the meeting, you could take the same note and stamp it as an email. A "to" field and a subject line would appear in the detail view. You would fill it out and click on a "send" button.

(Rosenberg: pp. 189-190)

I don't think any other existing PIM software allows you to do that. Apparently, many of these innovative features in Chandler are actually carried from Lotus Agenda, an old piece of software that Kapor wrote back in the Lotus days. It's a pity that today's PIM software is, for the most part, quite run-of-the-mill. When it comes to doing simple things (i.e., dealing with email or taking care of our appointments on a digital calendar) they are too complex and prone to corrupt our (valuable) data. As a matter of fact, it wouldn't be the first time I try to use one of these fancy applications and always end up reverting to good old time-tested mutt. No, mutt is not cool and fancy with all its bells and whistles, but it is extremely flexible, it lets me configure it precisely the way I want it and, above all, I can trust it with my email. I won't corrupt the data as soon as the email folders are too large, forcing me to deal with an emergency crisis at the worst possible moment. So, if I am going to use one of these newflangled applications, it'd better be something different, creative, innovative. It'd better be something that seemlessly links my email to my calendar, my tasks and my contacts. Otherwise, why even bother with a new app?

The rise of the web-centered paradigm.

Already back in 2003, the Chandler programming team had to answer a key question towards the beginning of their development effort: should they write a webapp or a traditional heavyweight desktop application?

Hertzfeld, impatient to move Chandler along, proposes a radical idea: Mozilla, he points out, is already structured to incorporate other programs as plug-ins. Why not build Chandler itself as one big Mozilla plug-in? Of course, he admits, there'd be problems. A browser-based design would certainly require a lot of rethinking of Chandler's goals. But relying on the browser's interface would save the programmers enormous amounts of the labor involved in building a new interface themselves.

"There's so much work ahead of us. It would be great to strap on some booster rockets," he says.

Michael Toy had often brought up the Mozilla option himself, but this time he raises cautions. "It's been forty thousand years since the invention of the Internet, and we still don't have a way for dumb people to make Web sites that are useful. And a Web browser is not a very good interface to something that is not the Web. It just seems like we'd be strapping a bad backpack on before we start walking".

(Rosenberg: pp. 154-155)

This was obviously before AJAX, Google Maps, Google Mail and a whole slew of other cool web applications Google (among others) has released in the past few years. I'd say by now we have finally reached a point where a webapp can do almost as much as a typical desktop application, and it certainly is the case already for things like email, tasks and calendars. As a matter of fact, there are plenty of users who already rely on web email for their work and personal communications. It's reliable, fast enough, OS independent, relieves the user from worrying about backups and, above all, it's mobile. It finally looks as if the time has come for the web to take over and render the underlying operating system almost irrelevant. This is something that many could see coming since the second half of the 1990s, but it truly didn't become a real possibility until these latest developments that took place in the past couple of years.

Work meetings that go into an infinite loop.

Ah, how did the following view exchange reminded me of so many work meetings!

"The question is," said Mitch Kapor, deep in the middle of a long meeting in a series of long meetings, "How do we sequence things to avoid spending an infinite amount of time before anything useful happens?"

"It's only infinite if you're stuck in a loop," Hertzfeld replied.

(Rosenberg: p. 152)

Vitruvius applied to software design.

Inspiration can truly come from anywhere, but when it comes to software design it is clear that there is a connection between it and architecture, as Kapor noted:

Software design, Kapor argued, was not simply a matter of hanging attractive graphics atop the programmer's code. It was the fundamental creative act of imagining the user's needs and devising structures in software to fulfill those needs. As the architect draws up blueprints for the construction team, so the software designer should create the floor plans and elevation views from which software engineers would work. Reaching back to ancient Rome, Kapor proposed applying to software the architecture theorist Vitruvius' principles of good design: firmness —sound structure, no bugs; commodity —"A program should be suitable for the purposes for which it was intended"; delight —"The experience of using the program should be a pleasurable one".

(Rosenberg: p. 149)

The terms may sound outdated, but the idea truly still applies: a well designed software should be solid and consistent, able to meet the requirements and a joy to use. Apple's designers have always put this advice to good use.

The paradox of reusable code.

The dream of code reuse has been with us for quite sometime. It promises to speed up the time it takes to write a given project and, even more important, it also promises sturdy, well tested components that may overtime become completely free of bugs. This is what people mean when they talk about modularity. Well, as Rosenberg explains in his book, code reuse is widespread these days and it does contribute towards solving some of the problems programmers had to deal with in the past —especially, it does speed up the time to completion. However, it is not free of its own problems.

Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won't handle are the very parts that make your new projects different, unique, innovative —and they're why you're building it in the first place.

(Rosenberg: p. 102)

This is almost by definition. A reusable component exists because a relatively high amount of people had a particular need in the past and it was written to satisfy that need. However, any project that is truly unique and innovative will have, by definition, needs that didn't exist before. It's one of those doh moments, isn't it?

However, there is another face to this paradox that's even more worrisome. What happens if a given project decides to use a particular reusable component from the get-go and later on finds the need to innovate and/or make some deep changes? Either they have to invest the time to learn the component —and we are talking about large and difficult pieces of programming here, such as Zope— or they have no other choice but to shoehorn their innovations into it. Needless to say, this leads to more bugs and, eventually, to an unmaintanable project.

Dreaming in Code.

The author tells us the story of a group of programmers who are trying to write a killer PIM app, something much better than MS Outlook and Exchange, which is overkill for most small businesses (not to talk about personal use). They are looking to build an open source peer-to-peer application that aspires to be far more flexible than anything else seen yet. But more important, the brains behind the whole operation happens to be none other than Mitch Kapor, the mythical programmer behind Lotus 1-2-3 and the name of the new application is Chandler. In any case, perhaps far more important than the particular story Rosenberg tells us about the experience of programming this particular application it's all the wonderful reflections about the history (and the job) of programming software that he shares with us.

Technical description:
Title: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software.
Author: Scott Rosenberg.
Publisher: Crown Publishers
Edition: New York (USA), 2007.
Pages: 400 pages, including index.
ISBN: 978-1-4000-8246-9