I like the heuristics described here.
However if these things aren't making it into a product spec where appropriate, then I smell some dysfunction that goes beyond what's being stored by default.
Product need (expressed as spec, design, etc) should highlight the failure cases where we would expect fields like these to be surfaced.
I'd hope that any given buisness shouldn't need someone with production database access on hand to inform as to why/when/how 'thing' was deleted. Really we'd want the user (be it 'boss' or someone else) to be able to access that information in a controlled manner.
"What information do we need when something goes wrong?". Ask it. Drill it. Ask it again.
That said, if you can't get those things, this seems a fine way to be pragmatic.
At an agency I worked for, we'd play back the gource during a project retro. An opportunity to reflect, or see which surprise characters turned up to throw something at the codebase.
I personally enjoyed those sessions, it gave non-coders an opportunity to point and ask questions about various clusters of nodes or find out why we were working on certain things at particular times.
A consistent display was a nice thing to count on when making little games, applets and ads. However for general web layout it made accessibility features difficult to impossible to implement.
I'd also add that behaviour wasn't always consistent. There would still be OS/environment specific bugs that would crop up from time to time. (Though granted, these would rarely be related to rendering or layout)
I like the heuristics described here. However if these things aren't making it into a product spec where appropriate, then I smell some dysfunction that goes beyond what's being stored by default.
Product need (expressed as spec, design, etc) should highlight the failure cases where we would expect fields like these to be surfaced.
I'd hope that any given buisness shouldn't need someone with production database access on hand to inform as to why/when/how 'thing' was deleted. Really we'd want the user (be it 'boss' or someone else) to be able to access that information in a controlled manner.
"What information do we need when something goes wrong?". Ask it. Drill it. Ask it again.
That said, if you can't get those things, this seems a fine way to be pragmatic.