Handling destructive updates in applications

One of the early lessons I learned after developing my first few web apps was to never actually delete records from a database. Even when the user clicked the “Delete” button it was almost always better to archive the data for undo or restore actions later then to actually delete the data. Storage space (even at the time) was cheap compared to the user’s data. Unless there was a good reason it was usually better to archive data then to delete it.

Over a decade later the vast majority of apps that I regularly use all provide undo or roll back functionality for deletes. Implementing this functionality is relatively easy (usually just a bit flag on a record) and a huge win for users.

A tougher problem to solve – and one that still gets skipped all too often – is the ability to undo destructive updates. The most robust way to handle this is to implement a versioning system. Wikis and most modern publishing systems (like Wordpress) do a this really, really well. Allowing users to rollback to easily compare with and roll back to previous versions of a text. The problem is that a good versioning system is not as trivial to implement as simply flipping a bit flag to undo a delete is.

As a result of this difficulty it’s common to see versioning on large text fields but completely ignored for most pages that control settings etc. (completely guilty of this myself). This is unfortunate.

I would advocate for meeting the users halfway: For areas where traditional versioning seems overkill (settings pages particularly) we can log all changes and make those logs available to users in some format. Even if a basic CSV download of the version history is provided I think this would be enough for 80% of the use cases and is vastly superior to nothing is the current standard for these types of pages.

comments powered by Disqus