4 ms·

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 f

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.)

errnesto 2y ago
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 :-)
- pjerem 2y ago
  > (that works by delaying the send a bit). 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.
  - Retric 2y ago
    True, on the other hand such delays help reinforce that email asynchronous rather than real time like chat programs.
  - IshKebab 2y ago
    Sending email is inherently asynchronous so the errors aren't an issue really.
pjerem 2y ago
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.
- pc86 2y ago
  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.

errnesto 2y ago

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 :-)

pjerem 2y ago
> (that works by delaying the send a bit). 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.
- Retric 2y ago
  True, on the other hand such delays help reinforce that email asynchronous rather than real time like chat programs.
- IshKebab 2y ago
  Sending email is inherently asynchronous so the errors aren't an issue really.

pjerem 2y ago

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.

pc86 2y ago
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.