5 ms·

Particularities elided, I was working on a POC of pretty critical (possible damage) closed loop (tightly controlled by operator at the time) system - basically

Particularities elided, I was working on a POC of pretty critical (possible damage) closed loop (tightly controlled by operator at the time) system - basically read inputs, react according to algorithm, rinse and repeat. Inputs, however, came from multiple unsynchronised sources and we could arrive at situations where output depended on multiple inputs. I guess we took pretty natural decision to use latest available value of inputs when needed. During one test run, one input did not update, we were happily feeding stale input to algorithm, which in turn took control paths that could have caused severe damages in unsupervised environment. Lessons learned: if you rely on invariants about inputs in code (update interval in this case), guard against violations of those invariants. This helped me many times later.

mooreds 9y ago
So basically treat even invariants as possibly varying.
- jeremiep 9y ago
  Invariants are still invariants. You just want some guarantee that they actually hold. Every time you use assert() somewhere you're doing just that.
- friendzis 9y ago
  Not necessarily. Very often we extract some invariants from data and embed them in code because it makes code much cleaner, easier to write, etc.. The problem is that some things that we assume (sometimes explicitly, sometimes by mistake) to be invariants are not necessarily invariants after all. Very, very unlikely to change, but not invariants nevertheless. I guess rather well-known real world example is systems starting to show weird behaviour when database resultset ordering changes (e.g. changes in indexing) and someone relies on correct entry being first/last. Assumed invariant here is resultset ordering and code is written with this particular invariant in mind. If not enough ordering clauses are used, resultset ordering is not invariant, even though it worked for years already :)

mooreds 9y ago

So basically treat even invariants as possibly varying.

jeremiep 9y ago
Invariants are still invariants. You just want some guarantee that they actually hold. Every time you use assert() somewhere you're doing just that.
friendzis 9y ago
Not necessarily. Very often we extract some invariants from data and embed them in code because it makes code much cleaner, easier to write, etc.. The problem is that some things that we assume (sometimes explicitly, sometimes by mistake) to be invariants are not necessarily invariants after all. Very, very unlikely to change, but not invariants nevertheless. I guess rather well-known real world example is systems starting to show weird behaviour when database resultset ordering changes (e.g. changes in indexing) and someone relies on correct entry being first/last. Assumed invariant here is resultset ordering and code is written with this particular invariant in mind. If not enough ordering clauses are used, resultset ordering is not invariant, even though it worked for years already :)