3 ms·

I was first paid to write a proper website in 1998, and having dev and prod was normal then. Fast forward to today and I believe developers shouldn't have acce

I was first paid to write a proper website in 1998, and having dev and prod was normal then. Fast forward to today and I believe developers shouldn't have access to prod data, ever, even to debug things. Privacy and security of user's data are more important than having a nice dev experience every time. If your work in an ISO27001 environment you don't really have much choice.

progre 4y ago
How are the developers supposed to debug things if they can't see the real data? Prod environments gets problems that never ever crops up in dev environments because the test data in those evironments are bounded by the developers imaginations. In prod, real users regularly do unimginable things.
- rizky05 4y ago
  [dead]
- onion2k 4y ago
  You have to actually understand what your code is doing rather than just winging it by accepting there'll be issues that you can fix if they show up. You end up writing a lot more defensive code - you rarely write things to reject improper values but instead you write guard functions that only accept proper values. You embrace the "parse don't validate" approach. You write generators and fuzzers that test APIs with thousands of variations of inputs rather than trying to think of "What would the user do?" You write a lot of things that would be 'pointless' and 'slow' in most organizations, but you don't really see bugs any more, or spend time firefighting and context switching, which counters that slowness significantly. I find it's a really enjoyably way to build software, and I've carried on doing it despite not working in an environment where I had to now.
  - progre 4y ago
    You'd need managment to really get what you are doing for that not to be career suicide. Because you will look like a slow ass developer, and since there is rarely problems you'd be mostly invisable. Compare that with devs or teams that get features out the door relatively swiftly: Sure, there is problems in production sometimes, but mostly fixed pretty fast too. A dev team like that looks like heroes.
    - onion2k 4y ago
      You'd need managment to really get what you are doing for that not to be career suicide. My management trusts me, mainly because the app I look after has far fewer reported defects and incidents than the rest of the company. I still haven't managed to persuade other teams to join me yet though. There's significant fear.
- brobdingnagians 4y ago
  What comes to mind is having someone with access to production who can replicate the type of data involved in a problem without the details that violate privacy. Though in some cases that is half of the debugging work done right there figuring out the type of data that breaks it.
funcDropShadow 4y ago
That goal of never debugging in production is understandable. But some companies have that software that falls in to the shit-in-shit-out category of software. By that, I mean software that does basically no input validation and consistency checks. The business never wants to think through all the cases, they are just willing to specify the minimum of requirements for the easy cases. In such an environment you have no chance without looking at the real pile of s.., hmm data. Obviously such companies should have an empty intersection with ISO27001-regulated once.

progre 4y ago

How are the developers supposed to debug things if they can't see the real data? Prod environments gets problems that never ever crops up in dev environments because the test data in those evironments are bounded by the developers imaginations. In prod, real users regularly do unimginable things.

rizky05 4y ago
[dead]
onion2k 4y ago
You have to actually understand what your code is doing rather than just winging it by accepting there'll be issues that you can fix if they show up. You end up writing a lot more defensive code - you rarely write things to reject improper values but instead you write guard functions that only accept proper values. You embrace the "parse don't validate" approach. You write generators and fuzzers that test APIs with thousands of variations of inputs rather than trying to think of "What would the user do?" You write a lot of things that would be 'pointless' and 'slow' in most organizations, but you don't really see bugs any more, or spend time firefighting and context switching, which counters that slowness significantly. I find it's a really enjoyably way to build software, and I've carried on doing it despite not working in an environment where I had to now.
- progre 4y ago
  You'd need managment to really get what you are doing for that not to be career suicide. Because you will look like a slow ass developer, and since there is rarely problems you'd be mostly invisable. Compare that with devs or teams that get features out the door relatively swiftly: Sure, there is problems in production sometimes, but mostly fixed pretty fast too. A dev team like that looks like heroes.
  - onion2k 4y ago
    You'd need managment to really get what you are doing for that not to be career suicide. My management trusts me, mainly because the app I look after has far fewer reported defects and incidents than the rest of the company. I still haven't managed to persuade other teams to join me yet though. There's significant fear.
brobdingnagians 4y ago
What comes to mind is having someone with access to production who can replicate the type of data involved in a problem without the details that violate privacy. Though in some cases that is half of the debugging work done right there figuring out the type of data that breaks it.

funcDropShadow 4y ago

That goal of never debugging in production is understandable. But some companies have that software that falls in to the shit-in-shit-out category of software. By that, I mean software that does basically no input validation and consistency checks. The business never wants to think through all the cases, they are just willing to specify the minimum of requirements for the easy cases. In such an environment you have no chance without looking at the real pile of s.., hmm data. Obviously such companies should have an empty intersection with ISO27001-regulated once.