Love this idea though not sure it's always practical. Sometimes features get so little use or are replaced so soon that the effort to maintain undo would mean fewer are affordable or ever even get to production.
All that said, for mature features, it does seem like a reasonable thing to require. Unless there are huge fundamentals standing in the way. (Like undoing forget-me requests days later.)
The thing is, this little feature that mostly nobody uses can be a disaster if used once.
At $work we had to implement a feature to delete a custom form object that was linked to maybe hundreds if not thousands of submissions to this form with cascade deletion. The thing is, submissions required something from dozens of minutes to multiple hours. The form was also pretty complex to build and could represent hours of work.
Still, we had to provide full (real) deletion of everything for legal reasons (and it’s hard to implement undo on this).
V1 was a classic "are you sure?"
It was a disaster for our support department and we had to recover data from our production backups way too many times.
V2 we added multiple confirmation boxes with something like "I understand I’m deleting x submissions", "I understand deletion is permanent and can’t be undone", "I understand $WORK support will not be able to help me recover ".
We still got way too much calls of people panicking about what they’ve done.
V3 was the same thing but we added some text to write (à la GitHub).
A little more effective but still not that effective.
The harsh reality is that people / brains just don’t read anything, they just click where they think they have to click.
Also this overkill confirm box would have been enough in a B2C context, but in B2B, you just can’t ignore people because they are stupid because they also pay you big money so they do expect you will solve their fuckups.
IIRC the next step was to implement a hidden undone mechanism like a fake deletion then a cron job does the real thing hours or days matter but it’s a rather expensive and complex thing to implement just to avoid some pretty rare overall (but massive) human errors. But I’m not there anymore.
I'm having a hard time seeing the link between "deleting a custom form object" and "delete thousands of submissions via cascade" from a business standpoint. These seem to me like they should always be separate actions, in separate screens. Most of my career has been Enterprise software and we (the engineers) have been asked to implement cascading deletes maybe a half dozen times and we've pushed back on it 100% of the time.
> The harsh reality is that people / brains just don’t read anything, they just click where they think they have to click.
Absolutely 100% true. The GitHub "danger section" / "type this long, possibly randomly generated, string of text to confirm you want to nuke everything forever" UI was a major step forward but at least for B2B dev stuff we're started to get used to that. I wonder what the next thing will be.
> in B2B, you just can’t ignore people because they are stupid because they also pay you big money so they do expect you will solve their fuckups
You can't ignore them but as long as you have executive backing you absolutely can (and should) say "there were three confirmation screens the data would be lost. The data is lost unless you want to pay Professional Services their hourly rate to go trudge through backups for a day to find it." If you don't have this backing leadership doesn't really care about the tech people and that's a separate issue.
> IIRC the next step was to implement a hidden undone mechanism like a fake deletion then a cron job does the real thing hours or days matter but it’s a rather expensive and complex thing to implement just to avoid some pretty rare overall (but massive) human errors. But I’m not there anymore.
This was my first thought, "delete" goes into a queue that gets processed later which gives people time to go "oh shit" and realize they messed up. We had something similar in a large healthcare company I worked at so probably similar legal requirements around storage of things and actually deleting them for real. We would put items into a queue for deletion, and the consumer of that queue was executed on a once-monthly schedule, but would only delete items that had been in that queue for 6 months already. This let any processing around quarter end or that sort of thing figure out something was wrong and gave it additional months to work its way to "find this piece of data and undelete it."
Pain in the ass to manage and would have been completely overkill if we weren't already using queues for basically everything.
> I'm having a hard time seeing the link between "deleting a custom form object" and "delete thousands of submissions via cascade" from a business standpoint.
I'm not going into further details, but those forms were there to accomplish some legal duty and each submission contained a lot of very personal information. The reason to delete those forms would always be that they were either created by error or that eventually they wouldn't be useful anymore.
But you are right that it could have been two features : one to delete all submissions then one to delete the form. That was one of my suggestions but it didn't pass some leadership / design validation.
> You can't ignore them but as long as you have executive backing you absolutely can
There are some reasons I'm not working there anymore :) It was a good company on many aspects but not this one.
-1: mark-for-deletion is generally best practice, where it doesn't create meaningful overhead in storage or performance. To optimize performance, consider a move-type operation, so expensive operations don't need to scan deleted data, but it's still online for the purposes of fast restore/recovery.
Conceptually, database backup/restore is effectively mark-for-deletion, but with a more difficult path to restoration, especially for one complex object.
If your database or framework/ORM supports it, my favorite solution is to use virtual tables that hide deleted data, so every the code is kept clean and developers don't accidentally query dead data.
> IIRC the next step was to implement a hidden undone mechanism like a fake deletion then a cron job does the real thing hours or days matter but it’s a rather expensive and complex thing to implement
I've done this before.[1] How did it work out to be expensive and complex to implement for your use-case? Did the "just deleted" elements have to be removed from any results-set as well?[2]
[1] Gather the data into a structure and throw that structure into a queue/bin/table with `now() + 5 days` as the expiry time.
[2] I've done this too, but not with a soft-delete column (which is a nightmare), but in a more complex way by writing the records to be deleted into a log, and then actually deleting them. This lets the user `undo` by showing them their entries in the log and asking which of those entries need to be restored.
Your task/job/goroutine/thread/script runs once every minute, retrieves all the structures/command/forms with `expiry > now()` and removes them.
My first thought was “yeah but there are also things you can not undo like sending e-mail” but then I remembered there is a really nice undo send button now (that works by delaying the send a bit).
Sure there are things you can not undo, sometimes you do want to permanently delete something, but maybe with a bit of thinking a undo is feasible more often then one might think :-)
A delay which can be annoying in its own way. It’s rarely an issue to be fair but it means you may not be informed of errors if you leave the mail client too soon. Also there are (admittedly very rare) cases where you want the mail to be sent immediately but it is sent at an unpredictable time : those undo features rarely display a countdown.
All that said, for mature features, it does seem like a reasonable thing to require. Unless there are huge fundamentals standing in the way. (Like undoing forget-me requests days later.)