Acronym Fatigue Series part 1: CAP, ACID and friends

  in this day and age, are there more useful concepts that we could be giving more attention than CAP, ACID, and friends? Are they useful enough to satisfy the dfsdt principle? I think not. 

CAP is useful to the extent that:

- people consciously declare that they have beaten it (in which case you have a very strong launchpad for your rebuttal, e.g. "Are you just pretending P won't happen?")

- or that they are sleepwalking into a software design which implicitly requires CAP capability to function well (in which case you know ahead of time that it will not function well, and so you should choose a different design).

ACID is a useful shorthand for "Can I rely on single-threaded reasoning while writing this multi-threaded program?" E.g. If I transactionally subtract 5 over here, and add 5 over there, then my code will not have changed the total amount. Since we now know DB vendors operate by default in a weaker isolation mode, we have a shorthand for knowing we can't use use single-threaded reasoning, and instead need to consider which commits over there will change the state of the running transaction over here.