6 ms·

Falsehoods that programmers believe: - Someone declared dead will never be declared alive again

deleted 4y ago
[deleted]
Joeri 4y ago
This applies to so many systems that have irreversible status transitions. I have seen this again and again over my career as a developer. A foolproof system is designed and then some fool of a user puts it in a different state from reality, after which it requires all kinds of tricking the system to make it match the observable universe. By now this should be system design 101: the system should always have an override to move a record from any state into any other state.
- SoftTalker 4y ago
  I try to design systems on an accounting principle. Every persistent state change is basically a journal entry, and you can always create a new entry to correct a prior entry.
  - moralestapia 4y ago
    This is almost always the right decision and it applies to pretty much any thing that needs to record anything. It also is one of the few down to earth use cases for a blockchain.
    - alasdair_ 4y ago
      > It also is one of the few down to earth use cases for a blockchain. Please no. It may be really difficult to get a human beaurocrat to fix something but can you imagine what it would be like if there was a smart contract that wasn’t coded with this possibility in mind?
      - moralestapia 4y ago
        Did I say anything about smart contracts? I think you've been brainwashed by the web3 gang. A blockchain is just a series of hash signatures that depend on each other, in this context you can use it to demonstrate integrity on the provided dataset. Period.
  - Brian_K_White 4y ago
    THIS. No unaccountable editing, but always allow new entries that accommodate the same needs. There is no legit reason any legit error correction can't have a log that shows the error and the correction. There are reasons, but no legit reasons.
  - incompatible 4y ago
    You could have a journal to record changes, but presumably you'd still have a single record for a person, with a single field for date of death, that would be set and then unset. Edit: I suppose it could be like addresses, if you had a separate address table and you'd be using the most recent address for a person without losing previous addresses. But it may seem like overkill for a field that's normally set only once.
- inglor_cz 4y ago
  I am just now programming a system where you can make a temporary deactivation and a permanent deactivation of a user account. And a permanent deactivation is irreversible from the UI, though it can be reversed by flipping a boolean in the DB proper. It is intended for situations where, e.g., the employee leaves the corporation. Should there be an override in the UI? Why? The way you are stating it sounds like a mathematical axiom, but I would like to see it treated as a theorem: with a proof, or at least a powerful set of reasons. I can see that a particular person may rejoin the same corporation later, but IMHO they should be given a new account, not just have their old account reactivated. They aren't really "the same person" anymore, they might have a different job description etc.
  - incompatible 4y ago
    They'd seem like the same person to me. Do people who switch jobs get a new account too?
    - inglor_cz 4y ago
      Now this is a good rebuttal. This app is only used for administration of networks, but who knows what the future may hold.
    - Gibbon1 4y ago
      Falsehoods programmers believe about jobs. When someone leaves the company they never come back.
- makeitdouble 4y ago
  Some systems need irreversibleness from a legal viewpoint. Image a voting machine for instance: at what conditions should it accept that the same person votes again ? In reality there must be situations where voiding a first vote and casting a second should be allowed. But for one, is it even possible IRL in most situations, for instance during a single day voting window ? For two, how would you make that an option that can be used at the level the reversing decision is taken, while also protecting from abuse from bad faith actors and corrupt elements ?

deleted 4y ago

[deleted]

This applies to so many systems that have irreversible status transitions. I have seen this again and again over my career as a developer. A foolproof system is designed and then some fool of a user puts it in a different state from reality, after which it requires all kinds of tricking the system to make it match the observable universe. By now this should be system design 101: the system should always have an override to move a record from any state into any other state.

SoftTalker 4y ago
I try to design systems on an accounting principle. Every persistent state change is basically a journal entry, and you can always create a new entry to correct a prior entry.
- moralestapia 4y ago
  This is almost always the right decision and it applies to pretty much any thing that needs to record anything. It also is one of the few down to earth use cases for a blockchain.
  - alasdair_ 4y ago
    > It also is one of the few down to earth use cases for a blockchain. Please no. It may be really difficult to get a human beaurocrat to fix something but can you imagine what it would be like if there was a smart contract that wasn’t coded with this possibility in mind?
    - moralestapia 4y ago
      Did I say anything about smart contracts? I think you've been brainwashed by the web3 gang. A blockchain is just a series of hash signatures that depend on each other, in this context you can use it to demonstrate integrity on the provided dataset. Period.
- Brian_K_White 4y ago
  THIS. No unaccountable editing, but always allow new entries that accommodate the same needs. There is no legit reason any legit error correction can't have a log that shows the error and the correction. There are reasons, but no legit reasons.
- incompatible 4y ago
  You could have a journal to record changes, but presumably you'd still have a single record for a person, with a single field for date of death, that would be set and then unset. Edit: I suppose it could be like addresses, if you had a separate address table and you'd be using the most recent address for a person without losing previous addresses. But it may seem like overkill for a field that's normally set only once.
inglor_cz 4y ago
I am just now programming a system where you can make a temporary deactivation and a permanent deactivation of a user account. And a permanent deactivation is irreversible from the UI, though it can be reversed by flipping a boolean in the DB proper. It is intended for situations where, e.g., the employee leaves the corporation. Should there be an override in the UI? Why? The way you are stating it sounds like a mathematical axiom, but I would like to see it treated as a theorem: with a proof, or at least a powerful set of reasons. I can see that a particular person may rejoin the same corporation later, but IMHO they should be given a new account, not just have their old account reactivated. They aren't really "the same person" anymore, they might have a different job description etc.
- incompatible 4y ago
  They'd seem like the same person to me. Do people who switch jobs get a new account too?
  - inglor_cz 4y ago
    Now this is a good rebuttal. This app is only used for administration of networks, but who knows what the future may hold.
  - Gibbon1 4y ago
    Falsehoods programmers believe about jobs. When someone leaves the company they never come back.
makeitdouble 4y ago
Some systems need irreversibleness from a legal viewpoint. Image a voting machine for instance: at what conditions should it accept that the same person votes again ? In reality there must be situations where voiding a first vote and casting a second should be allowed. But for one, is it even possible IRL in most situations, for instance during a single day voting window ? For two, how would you make that an option that can be used at the level the reversing decision is taken, while also protecting from abuse from bad faith actors and corrupt elements ?