[3rodents]

Soft deletes are an example of where engineers unintentionally lead product instead of product leading engineering. Soft delete isn’t language used by users so it should not be used by engineers when making product facing decisions.

“Delete” “archive” “hide” are the type of actions a user typically wants, each with their own semantics specific to the product. A flag on the row, a separate table, deleting a row, these are all implementation options that should be led by the product.

[dpark]

> Soft delete isn’t language used by users so it should not be used by engineers when making product facing decisions.

Users generally don’t even know what a database record is. There is no reason that engineers should limit their discussions of implementation details to terms a user might use.

> “Delete” “archive” “hide” are the type of actions a user typically wants, each with their own semantics specific to the product.

Users might say they want “delete”, but then also “undo”, and suddenly we’re talking about soft delete semantics.

> A flag on the row, a separate table, deleting a row, these are all implementation options that should be led by the product.

None of these are terms an end user would use.

[pjerem]

> Users might say they want “delete”, but then also “undo”, and suddenly we’re talking about soft delete semantics.

I've worked for a company where some users managed very personal informations on behalf of other users, like, sometimes, very intimate data and I always fought product on soft deletion.

Users are adults, and when part of their job is being careful with the data _they_ manage and _they_ are legally responsible for, I don't feel like the software owes them anything else than a clear information about what is going to happen when they click on "CONFIRM DELETION".

"Archive" is a good pattern for those use cases. It's what have been used for decades for OS "Recycle Bin". Why not call it Delete if you really want to but in this case, bring a user facing "Recycle Bin" interface and be clear than anything x days old will be permanently deleted.

[indigo945]

Right, but I think that the Recycle Bin is exactly what is causing the issue here. Users have been taught for decades that if they delete something, it is not really gone, as they can always just go back to their Recycle Bin or Deleted Items folder and restore it. (I have worked with clients that used the Deleted Items folder in Outlook as an archive for certain conversations, and would regularly reference it.)

So users have been taught that the term "delete" means "move somewhere out of my sight". If you design a UI and make "delete" mean something completely different from what everyone already understands it to mean, the problem is you, not the user.

[dpark]

> Users have been taught for decades that if they delete something, it is not really gone

There are stories all over the internet involving people who leave stuff in their recycle bin or deleted items and then are shocked when it eventually gets purged due to settings or disk space limits or antivirus activity or whatever.

Storing things you care about in the trash is stupid behavior and I hope most of these people learned their lessons after the one time. But recycle bin behavior is beneficial to a much larger set of people, because accidental deletion is common, especially for bulk actions. “Select all these blurry photos, Delete, Confirm, Oh, no! I accidentally deleted the last picture of my Grandma!”

Recycle bin behavior can also make deletion smoother because it allows a platform to skip the Confirm step since it’s reversible.

[arter45]

End users do all kinds of stuff, but as a developer you're supposed to gather (even elicit, at times!) requirements from users or stakeholders who act as proxies for actual users.

Store something so you can read it in a year or even after a blackout is a user requirement, which leads to persistence.

And if this is a user requirement, deleting ("un-storing") is a user requirement too.

"I want to delete something but I also want to recover it" is another requirement.

Of course,you could also have regulatory requirements pointing to hard-deleting or not hard-deleting anything, but this also holds for a lot of other issues (think UX - accessibility can be constrained by regulations, but you also want users to somehow have a general idea of the user experience).

[monkpit]

Why would implementation details be led by product? “Undo” is an action that the user may want, which would be led by product. Not the implementation in the db.

[strken]

I believe that was the point. Soft delete isn't a product requirement, it's an implementation detail, so product teams should talk about the user experience using language like "delete" or "archive" or "undo" or "customer support retrieves deleted data".

[Terr_]

Yeah: You don't "delete" a bank account, you close it, and you don't "undo", you reopen it, etc. The processes have conditions, audit rules, attached information, side-effects, etc. In some cases the same entity can't be restored, and you have to instead create a successor.

"Undo" may work as shorthand for "whatever the best reversing actions happen to be", but as any system grows it stops being simple.

[dpark]

Sure. Did someone say that the behavior should be described to customers as soft delete, though?

I read a blog about a technical topic aimed at engineers, not customers.

[nitwit005]

I'd be careful of thinking of everything as product facing or not. Many features are for support, legal compliance, etc.

It's fairly common in some industries to get support requests to recover lost data.

[antonvs]

It depends on the product. Google Cloud Storage has a soft delete feature in its product, for example: https://docs.cloud.google.com/storage/docs/soft-delete