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

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