I have started using a very simple and rough version of the Whatnext (my proof-of-concept nihilistic productivity planner) as my task list; it's marginally better than the Google spreadsheet I was using, but marginal is better enough when you want to eat a little dogfood. The very second thing I did, after dancing with glee that I got something useful onto the internet in only 53 hours of work (plus 83 for getting the website back up and learning the basics of Django programming), was screw something up. The third thing was to get annoyed because there's a confirmation step to deletion.
Why did I make it have a confirmation step? I didn't—I followed the example for the tool I'm using, Django class-based views (I am continuing to blur any technical terminology in these programming essays so as to avoid scaring or boring). I don't want to scrap the confirmation because, of course, I am terrified of deleting anything by accident. Usability guru Jakob Neilsen argues that undo is more usable than confirmation. More generally, I suspect that begging forgiveness is more usable than asking permission as long as forgiveness is easy enough to grant. So, let's fix this by changing it from Confirmation to Undo.
Okay, easy enough, I'm plenty familiar with the "Soft delete" pattern, which is that you don't actually delete anything in the database, you just mark it as deleted and then exclude it from normal use. And Django has a handful of packages to make it easy. However, googling for best practices leads to this apparent ur-objection: The trouble with soft delete.
it usually ends up causing more harm than goodSimilarly:
[Soft delete is s]imple, easy to understand, quick to implement and explain.
It is also, quite often, wrong.Even more:
I just do not like this kind of design at all. I am firm believer of the architecture where only necessary data should be in single table and the useless data should be moved to an archived table.Ugh. I just want delete stuff without having to click twice and without risking losing something I wanted. I want an undo, like Gmail:
(By the way, if you ever wished you could unsend an email right after you sent it, because it's only when you click send that your brain finishes figuring out what you want to say or not say and who you want to say it to or exclude, and you use Gmail, you should totally turn on undo. I'm sure I use it more than once a week.)
I don't have time to read all of those links and reach an informed position in this debate. I just want an undo button. I keep browsing as a way of stalling, and see that someone else suggests yet another pattern: "the Command Pattern." I start reading the link:
Command is a very powerful design pattern, whose intent is to encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.Yeah, no, I'm not going to even read enough to understand what that means. Okay, I want to finish dealing with the delete confirmation in ten minutes or less. And we are back to the classic programmer problem: should I do it the expedient way or the best way? I think I'm going to compromise: I'm going to switch to Soft Delete for the moment, because it's expedient and a very reversible decision. But I'm not going to build the undo yet, because that's going to take a while and I already have a task later on to figure out how to do the yellow notifications. If I really need to undo I can duck under the covers. And I've bookmarked all of those articles to read through and then consider which alternative to Soft delete, if any, is best for Whatnext.
I guess that's not a compromise; that's doing a quick and dirty partial fix to the immediate problem (which, if you remember, is that the delete confirmation annoys me) and punting on everything else. In my next essay on this subject, I should probably tell you about the term "Technical Debt," because I just incurred some. Meanwhile, go set up undo on your Gmail.