Some things are trivial and nearly free - created_at, updated_at. I don't think engineers need to bring trivialities like this to a "product owner". Own your craft.
When the product you're developing is governed by regulations and standards you need to comply, owning your craft is doing things by the book, not adding fields on your own because it might be useful later.
So what? I've worked places with lots of regulation. Part of every development job is learning the product domain. In that case devs become comfortable with reading standard/law/regulations and anticipating when software implementation might interact with the areas covered.
Sure there were people who's job was to offload as much compliance work from everyone else; by turning it into internal requirements, participating in design discussion and specializing in ensuring compliance. But trying to isolate the development team from it is just asking for micromanagers.
Think before you act. The machine has no brain. Use yours.
> Part of every development job is learning the product domain.
Yes.
> In that case devs become comfortable with reading standard/law/regulations and anticipating when software implementation might interact with the areas covered.
This is what I'm saying, too. A developer needs to think whether what they are doing is OK by the regulation they're flying against. They need to ask for permissions by asking themselves "wait, is this OK by the regulation I'm trying to comply?".
> But trying to isolate the development team from it is just asking for micromanagers.
Nope, I'm all for taking initiatives, and against micromanagement. However, I'm also against "I need no permission because I'm doing something amazing" attitude. So own your craft, "code responsibly".
Oh, I thought you were disagreeing with hamandcheese's point that every little decision doesn't need to go through a product owner before anything happens.
But it happens to be that product managers know (or at least about) and keep tabs on the relavent regulatory environment. I think it’s not scalable if every SWE in the team is going to legal to understand things. Like why we actully do need to hard delete data when customers click the Delete button.
If you force every SWE to go to legal for every technical decision, or ask for permission, it's not scalable, yes. On the other hand, if the team is in the long haul of developing this kind of regulated applications, the knowledge will get accumulated over time, and it'll trickle down from product managers to seniors to juniors.
This is the kind of tribal knowledge you want to spread among a development team, and if a collaborative document of "Why it's done this way" can be propped up with pointers to relevant sections of the regulation, it'd be a very good thing.
I think the tricky part lies on knowing which things can be done without consulting any product owner. I agree that created_at and updated_at don’t cause any harm. deleted_at on the other hand cannot be decided by engineers only (mainly because of GDPR reasons: if something is expected to be totally deleted, then that must be it). As usual, these kind of things are obvious to engineers with years of experience , not so much to newcomers.
Soft deletes can be done in a GDPR-compliant way. But transparency is key.
The problem of course is that soft deletes are hard. As soon as you take sub-resources and relations into considerations, especially with shared ownership, things get complicated. SQL databases can usually handle cascading deletes and nulling but that doesn't work with soft deletes - also, if a soft delete exists to allow for a restore, how do you handle references you would null in an actual delete? Now you need to either track the deleted value or add logic to every query involving that reference to filter out soft deletes in addition to null references (which adds query complexity).
Although those can be more complicated, and it should be clear what they're for and why they exist. Will this result in an object having an updated_at timestamp elsewhere in a larger application? Is it clear which properties that refers to?
