4 ms·

This feels incredibly negligent. It seems obvious that generating thousands of random phone numbers and locking them without any other checks would lock some re

by quenix 5y ago

This feels incredibly negligent. It seems obvious that generating thousands of random phone numbers and locking them without any other checks would lock some real phones. I'm puzzled that the author did not consider this when writing the script, let alone testing it or running it on live prod servers.

heavenlyblue 5y ago
I don't understand how people can defend this developer in the first place. I could understand if they were about 16 years old and actually abused by their employer, but generating random numbers to test the locking of phones? Basic maths should tell you that the probability of matching some real phone number is actually quite high. Moreover, what exactly were they testing? i.e. if they were testing nonexistent numbers, then how would they even know the phones were blocked in the end?
- shaan7 5y ago
  > Basic maths should tell you that the probability of matching some real phone number is actually quite high. Yeah well, the thing about pressure (of the sort the author has describing) is that you make mistakes - the kind where some times 3+3 = 9. Source: I queued jobs to nuke the whole production database (relax, we had automated backups+verification so we recovered fast enough; and then added some gating so make this more difficult in the future)
- throwdecro 5y ago
  Being somewhat generous, I don't think it's because they didn't understand the probabilities, it's because they didn't think about the impact of what they were doing at all, beyond the problem they needed to solve. I.e., the only thing they were considering was whether the number entered at the start of the test would show up in the right places at the other end of their system. They simply didn't consider that an actual phone would be shut off along the way.
- jihadjihad 5y ago
  I pass no judgment, but merely take the developer at his word: https://new.pythonforengineers.com/blog/confessions-of-a-1x-programmer/ https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
  - polartx 5y ago
    Why would he write and _publish_ this?!? Is this some kind of humiliation fetish? These are things that should maybe be admitted in a confessional, or therapy.
  - svrourke 5y ago
    This link is the cure to imposter syndrome, this is an actual imposter. I don't think they're even actually interested in programming and I cannot comprehend why they do it as a job or why they got hired.
cycomanic 5y ago
Too me this is another example showing how much behind "software engineering" is behind most otherl engineering disciplines. Processes in other disciplines are build very much into the practice that these things don't happen because people die if a plane crashes or a bridge collapses. Also that somehow software gets away with absolving itself of any liability (i.e. the usual "this software is provided as is...") is quite remarkable.
- treesknees 5y ago
  You're just not looking in the right places, and your comment is a bit disingenuous. You're cherry-picking examples that don't represent an entire industry. NASA for example has an _extremely_ tight tolerance on software specifications, testing, and proofs [1]. Medical devices and other core infrastructure also has very robust development cycles to ensure bugs don't bring down the power grid or overcharge someones heart in a pacemaker. Meanwhile you can look at the auto industry and find example after example of shoddy engineering or manufacturing processes putting hundreds of thousands of drivers and families at risk. [2] [3] [4] 1 - https://www.nasa.gov/isd-robust-software-engineering https://www.nasa.gov/isd-robust-software-engineering 2 - https://news.yahoo.com/chevy-bolts-stressful-recall-161700057.html https://news.yahoo.com/chevy-bolts-stressful-recall-16170005... 3 - https://www.consumerreports.org/car-recalls-defects/takata-airbag-recall-everything-you-need-to-know-a1060713669/ https://www.consumerreports.org/car-recalls-defects/takata-a... 4 - https://www.cars.com/articles/explaining-the-toyota-floormat-recall-1420663233094/ https://www.cars.com/articles/explaining-the-toyota-floormat...
  - 6gvONxR4sf7o 5y ago
    It seems pretty clear that software is behind the auto industry in build quality/reliability too.
- travisgriggs 5y ago
  It’s like trying to breathe underwater. Just because a person has the capability and know how to breathe, they can’t breathe if not given the proper environment to do so. Yelling at them “why didn’t you take a breathe?!?!” As you watched them drown underwater is just ridiculous and naive. But every time proper engineering doesn’t happen, we see a subset of cries like this, like it’s some moral failing in the engineer. There are surely some chronically stupid engineers out there, but 99% of the time it’s a culture that has subverted the doers below the discussers and the deciders that leads to this shitshow of “how did this happen??”
treesknees 5y ago
Not defending him, but he does state that unlike the other mobile providers he's worked with, this K-Pop company's backend system would lock _any_ phone number, not just the ones they're responsible for. Perhaps he didn't know this. I bet normally he'd generate random numbers not associated with the provider, check they show up as "locked" in the database, under the assumption that the backend actually doing the locking signal would reject the numbers due to them being under control of another operator. It's similar to our networking lab where we generate bogus traffic using random src/dst IP addresses under the assumption that our null routes and firewall will block them from the real Internet. In this case, the provider just decided no firewall was needed. We can't use "fake" IP addresses (yes there are IP ranges for internal use but that doesn't work for certain testing scenarios.)
- polartx 5y ago
  The fact that he was running production code and not writing the result to any kind of log file, which would only take a couple more lines of code, one more dependency (if he wanted to skip some time rolling his own), and a couple of megs of storage, is so absurdly irresponsible, I’m surprised he wrote this post up at all—most would be too embarrassed.

by quenix 5y ago

heavenlyblue 5y ago

I don't understand how people can defend this developer in the first place. I could understand if they were about 16 years old and actually abused by their employer, but generating random numbers to test the locking of phones? Basic maths should tell you that the probability of matching some real phone number is actually quite high. Moreover, what exactly were they testing? i.e. if they were testing nonexistent numbers, then how would they even know the phones were blocked in the end?

shaan7 5y ago
> Basic maths should tell you that the probability of matching some real phone number is actually quite high. Yeah well, the thing about pressure (of the sort the author has describing) is that you make mistakes - the kind where some times 3+3 = 9. Source: I queued jobs to nuke the whole production database (relax, we had automated backups+verification so we recovered fast enough; and then added some gating so make this more difficult in the future)
throwdecro 5y ago
Being somewhat generous, I don't think it's because they didn't understand the probabilities, it's because they didn't think about the impact of what they were doing at all, beyond the problem they needed to solve. I.e., the only thing they were considering was whether the number entered at the start of the test would show up in the right places at the other end of their system. They simply didn't consider that an actual phone would be shut off along the way.
jihadjihad 5y ago
I pass no judgment, but merely take the developer at his word: https://new.pythonforengineers.com/blog/confessions-of-a-1x-programmer/ https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
- polartx 5y ago
  Why would he write and _publish_ this?!? Is this some kind of humiliation fetish? These are things that should maybe be admitted in a confessional, or therapy.
- svrourke 5y ago
  This link is the cure to imposter syndrome, this is an actual imposter. I don't think they're even actually interested in programming and I cannot comprehend why they do it as a job or why they got hired.

cycomanic 5y ago

Too me this is another example showing how much behind "software engineering" is behind most otherl engineering disciplines. Processes in other disciplines are build very much into the practice that these things don't happen because people die if a plane crashes or a bridge collapses. Also that somehow software gets away with absolving itself of any liability (i.e. the usual "this software is provided as is...") is quite remarkable.

treesknees 5y ago
You're just not looking in the right places, and your comment is a bit disingenuous. You're cherry-picking examples that don't represent an entire industry. NASA for example has an _extremely_ tight tolerance on software specifications, testing, and proofs [1]. Medical devices and other core infrastructure also has very robust development cycles to ensure bugs don't bring down the power grid or overcharge someones heart in a pacemaker. Meanwhile you can look at the auto industry and find example after example of shoddy engineering or manufacturing processes putting hundreds of thousands of drivers and families at risk. [2] [3] [4] 1 - https://www.nasa.gov/isd-robust-software-engineering https://www.nasa.gov/isd-robust-software-engineering 2 - https://news.yahoo.com/chevy-bolts-stressful-recall-161700057.html https://news.yahoo.com/chevy-bolts-stressful-recall-16170005... 3 - https://www.consumerreports.org/car-recalls-defects/takata-airbag-recall-everything-you-need-to-know-a1060713669/ https://www.consumerreports.org/car-recalls-defects/takata-a... 4 - https://www.cars.com/articles/explaining-the-toyota-floormat-recall-1420663233094/ https://www.cars.com/articles/explaining-the-toyota-floormat...
- 6gvONxR4sf7o 5y ago
  It seems pretty clear that software is behind the auto industry in build quality/reliability too.
travisgriggs 5y ago
It’s like trying to breathe underwater. Just because a person has the capability and know how to breathe, they can’t breathe if not given the proper environment to do so. Yelling at them “why didn’t you take a breathe?!?!” As you watched them drown underwater is just ridiculous and naive. But every time proper engineering doesn’t happen, we see a subset of cries like this, like it’s some moral failing in the engineer. There are surely some chronically stupid engineers out there, but 99% of the time it’s a culture that has subverted the doers below the discussers and the deciders that leads to this shitshow of “how did this happen??”

treesknees 5y ago

Not defending him, but he does state that unlike the other mobile providers he's worked with, this K-Pop company's backend system would lock _any_ phone number, not just the ones they're responsible for. Perhaps he didn't know this. I bet normally he'd generate random numbers not associated with the provider, check they show up as "locked" in the database, under the assumption that the backend actually doing the locking signal would reject the numbers due to them being under control of another operator. It's similar to our networking lab where we generate bogus traffic using random src/dst IP addresses under the assumption that our null routes and firewall will block them from the real Internet. In this case, the provider just decided no firewall was needed. We can't use "fake" IP addresses (yes there are IP ranges for internal use but that doesn't work for certain testing scenarios.)

polartx 5y ago
The fact that he was running production code and not writing the result to any kind of log file, which would only take a couple more lines of code, one more dependency (if he wanted to skip some time rolling his own), and a couple of megs of storage, is so absurdly irresponsible, I’m surprised he wrote this post up at all—most would be too embarrassed.