60 ms·
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. The
by 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.
- pjerem 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. 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.