On Auto Save

I was just coding up something Eclipse for work and decided I wanted to pop a dialog to ask the user "Do you want to save?" I did a quick Google search to see if I could find the name of dialog I wanted - and instead, ran across this blog post. The author, in a nutshell, through the post and his subsequent comments, argues that asking the user to save is a bad thing and, instead, your program should always be saving - but in such a way that it is possible to roll back the changes.

At first blush, that seems like a really good idea. If the program is always saving, you never need to worry about losing your work, so you never need to stop and think "now I want to save" - and hence can't forget to do it. Likewise, if you discover that you've been going down the wrong path, you can always step back and reverse your changes (just undo until you get back to where you would have preferred to be). Presumably, the program will even reload your undo history when you reload a given document.

Here's the problem. "Save" does more than just commit a set of recent changes to non-volatile storage. It's also an expression of intent that means "and now I've made a meaningful set of changes to which I want to be able to return (in the event of a crash, etc.)." In some circumstances, these two things are equivalent (or very nearly so). For instance, when I'm typing a blog, I might periodically be saving my entry because, after all, any change I've made is meaningful. Sure, I might decide later to back up, but there's no problem if basically every change I make is saved.

This is simply not true in all circumstances. Imagine, instead, a database application with hundreds (or thousands or millions) of users, all of whom are working on pieces of a single, centralized data store. Anne opens a form to edit an entry in one of the records on the database. As she makes changes, she effectively breaks things - while updating field 1 but not having had a chance to update fields 2 and 3, the entry is now in an inconsistent state: its data no longer makes sense and should not - or cannot - be committed back to the database. If it were committed (if the database allowed it), Bob might see some of Anne's changes but not all of them and he might either be thoroughly confused, or take some incorrect action based on the inconsistent data.

Save, then, becomes the mechanism by which Anne says "And now my data is consistent and should be visible to all users of this database." Likewise, should Anne try to close the form through which she is editing the entry, the software well and truly should ask her "are you sure you don't want to save those changes?" Here, save is a clear expression of intent and cannot be serviced with auto save plus versioning.

One final thought: it's tempting to say that the software should ensure that Anne cannot make changes to any entry and in so doing put that entry in an inconsistent state - even temporarily. But that assumes that there is some mechanism by which the software can "guess" at reasonable or correct values for all related fields when any one of them is changed. In the case of a set of related dates (Earliest Launch Time, Latest Launch Time, Preferred Launch Time), this is easily handled. In general, simple solutions cannot be found: when updating code, for instance, how is the software supposed to guess at a correct set of actions to take in response to an arbitrary line being updated? Anne must make the changes she had in mind and then signal to the software that now her changes should be committed and thus should be visible to all users.