3 ms·

Bugs caused by edge-cases in data are exactly the types of bugs that are usually not caught in smoke tests. In my experience with large regulated systems, the

Bugs caused by edge-cases in data are exactly the types of bugs that are usually not caught in smoke tests. In my experience with large regulated systems, the engineers writing the software don't have the expertise to even know what the correct specifications should be in most cases, and especially in edge cases. Software engineers are not experts in customs and immigration legal requirements and would be relying on heavily on guidance from experts in those fields to determine the proper rules to apply. In my experience with bugs like this, it is usually scenarios that all parties involved in the design did not consider... especially when implementation is rushed due to tight deadlines.

aleph_minus_one 2mo ago
My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that. Other stakeholders typically don't apply such caution.
- kube-system 2mo ago
  Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
  - aleph_minus_one 2mo ago
    > That being a slow process is not a software engineering issue, but an organizational issue. Business software is work processes that has been turned into code.
    - kube-system 2mo ago
      Yes, but the end users are not (yet) code, they are humans. In order to fix the data in the system, the organization will have to place a human behind the keyboard with the authority and ability to change the data from incorrect to correct.
      - aleph_minus_one 2mo ago
        > will have to place a human behind the keyboard with the authority [...] to change the data from incorrect to correct. Whether such a person has such a permission in the system or whether the permission system of the software can actually model this is a work process that has been turned into code.
        kube-system 2mo ago
        Yes, the permissions systems in software usually is built to reflect the reality of someone's job role.

aleph_minus_one 2mo ago

My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that. Other stakeholders typically don't apply such caution.

kube-system 2mo ago
Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
- aleph_minus_one 2mo ago
  > That being a slow process is not a software engineering issue, but an organizational issue. Business software is work processes that has been turned into code.
  - kube-system 2mo ago
    Yes, but the end users are not (yet) code, they are humans. In order to fix the data in the system, the organization will have to place a human behind the keyboard with the authority and ability to change the data from incorrect to correct.
    - aleph_minus_one 2mo ago
      > will have to place a human behind the keyboard with the authority [...] to change the data from incorrect to correct. Whether such a person has such a permission in the system or whether the permission system of the software can actually model this is a work process that has been turned into code.
      - kube-system 2mo ago
        Yes, the permissions systems in software usually is built to reflect the reality of someone's job role.