4 ms·
> For example, suppose there is bug where the rate calculations aren't working for certain types of routes. The engineers will want to look up those routes to u
by vageli 9y ago
> For example, suppose there is bug where the rate calculations aren't working for certain types of routes. The engineers will want to look up those routes to understand what is causing it.
Then show routes without names.
> If you are designing an algorithm to detect to fraud, you are going to want to look at cases of fraud to understand how to design the algorithm.
Then show names without routes.
> Further, if you want to do usability testing you are going to need to test with. You might want to check the different types of names used in the system to make sure they display properly. You may also want to sample the list of customers to user-test with live data or survey customers.
Use a library that can generate realistic but fake data. I feel there is no excuse to not compartmentalize. If data security is not important to the business...well it only takes one bad article like this to cast doubt on the whole company.
- djsumdog 9y agoThe trouble is, if you're at this level of engineering, you're probably going to be writing the isolation layer. So you already have access to the raw data and you're just going to either make things harder for yourself or only be designing for downstream security. You can and should restrict customer service reps (only allow them to access routes/users/drivers who they have active tickets on), but at some point you're going to need to trust your developers since they can usually just query the database directly.
- mattmanser 9y agoAs I said in another comment, there's absolutely no need for an engineer to have access to live data in normal circumstances. Learning how to recreate bugs without trace stacks or live data is a debugging skill you can learn. Often it's as simple as following the steps described in the ticket, something some developers seem to not realize, or their reading comprehension is bad. For really complex bugs, you might need some sort of access to see the specific conditions, but it should be attempted with an anonymized version of the db that you had to request and get signed off on. If you then really need to put in tracing, if should be temporary, the data access should be heavily restricted and it should be deleted/removed once the bug is fixed.
- newfoundglory 9y ago> Often it's as simple as following the steps described in the ticket, something some developers seem to not realize, or their reading comprehension is bad. That sounds like a pretty simple set of bugs you are dealing with. I don't think anyone is arguing that they need this level of information to solve "When I click this button it crashes".