Calendaring is Hard...

Feb 15, 2011 13:25


I was out to lunch with a friend today, and we got on the topic of computerized calendaring. Virtually everyone I know consumes computerized calendaring, and when it comes up, without fail, they all complain about it. I've heard people say, "Gmail is a great way for me to do email," but no one ever says, "X is a great way for me to do calendaring," for any value of X I've ever heard of. Mostly, they seem to say one of two things -- either:
  • We use Outlook/Exchange, and while we hate it, it mostly does what we need, and I know everything else is worse.

or
  • We use X, and we mostly get by, but I hate it, and recognize that we'd probably be better off with Outlook/Exchange.

It was easy for my friend and I to concur that Microsoft does it best, but still sucks. Then, we puzzled for a second on the question, "Why is calendaring so hard?" and an idea hit me -- I don't know whether it's correct or not, but it snapped into sharp focus for me in an instant, so I figured I'd share it here.
Software for Calendaring is hard because the problem is inherently NOT about abstraction, it's about concrete details.

To explain further: As a software engineer, I spend most of my days looking for better and better abstractions for whatever problem space I'm dealing with right now. To give an example from my work on charting, you can think of a chart as having X and Y axes, but that's a concrete detail. What charts really have are abstract axes of measurement. A cartesian chart is but one reification of that abstraction. In many software systems abstraction is your friend. By working in abstractions you earn code reuse as well as, hopefully, structural self-evidence.

Now let's think about calendaring. While I'm sure there are plenty of "abstractions" manifesting in any calendaring software, the measure of success for a given system will end up being decided by the execution of the details, and there are plenty of details. Leap years, time zones, conflict resolution, recurrence, alarms, the list goes on and on. What's worse is that there's a certain set of these issues where a single failure renders your calendaring software to be "a total piece of shit" in the hearts and minds of the users. For me, these issues tend to center around reminders; I rely on them. When whatever calendaring software I use fails to remind me of an obligation, and I happen to miss it, that software is instantly the target of my hatred. Furthermore, once a piece of calendaring software has failed me three or four times (an understatement for every system I've used other than Outlook/Exchange) I inherently never trust it again, and hatred and distrust of it festers. But, I digress.

It seems to me that the crux of the issue is that abstractions don't help calendaring software execute on calendaring. Abstractions help humans execute on calendaring, because humans are imprecise, but they hurt calendaring software, because once you have precision the problem is inherently about concrete details. Even worse, it's also about having those precise, concrete details line up consistently with the imprecise human mental abstractions around calendaring.

And in the common case, all this grief is just to get the Gregorian calendar right. Then you get to try to get it right for every other calendar used everywhere in the world, or even worse, historically. It's doomed.

Calendaring is hard.
Previous post Next post
Up