3 ms·

Discussed elsewhere in the thread, it's definitely not needed day to day. The number of devs popping up in this thread who think routine access is needed to li

Discussed elsewhere in the thread, it's definitely not needed day to day. The number of devs popping up in this thread who think routine access is needed to live data just to be able to debug is quite worrying. In the rare instances it is, an anonymized version of the live db should be used to recreate the bug. If this doesn't work, then you might put in temporary logging accessible to only approved people, which is removed after the bug is fixed and the logs deleted. To be a bit more explicit, I think small companies have a justifiable reason to be a bit more relaxed about live db access, but once you get to having larger teams of people, you're under a huge risk of a malicious actor. Which is easily mitigated by restricting access.

newfoundglory 9y ago
From reading all of your comments here, it occurs to me that you might just not be talking about the kind of software that involves actually processing user data as the service. When customer data is incidental to the core engineering work, then yes you should be able to abstract it away. When the service is "upload your data and we will perform analysis on it and give you results", then it really does require that data to figure out why this customer says their results aren't making sense.
chaostheory 9y ago
> it’s definitely not needed day to day Yes I agree which is why that was the first sentence of my comment, which was in response to your comment which stated, “No-one needed access... Engineers never did.” It’s great that you changed your position, but please don’t make it seem like I was advocating for unfettered, 24/7 access to customer data when I clearly didn’t write that