[xnorswap]

But it's not a useful checklist, particularly if it doesn't have examples. Your post is more informative than the whole article, because it's a concrete example of where an assumption went wrong.

I could say, "Falsehoods programmers believe about databases:"

And say

* Transactions are atomic

But it's not helpful without examples of when and why they're not atomic.

And it's not helpful to programmers to write their software as if transactions are not atomic. The ability to think about transactions as atomic is a fundamental of the database system.

A programmer is far more effective if they leverage the fact that their DB does have atomicity guarantees and write their software accordingly, rather than slowing everything down by trying to code around an assumption they are not, because perhaps in just the right failure mode or configuration of the right database product, they might not be.

That's why examples are so important, because going through this checklist in code review is a huge waste of time if it's not actually applicable. Being able to leverage assumptions about a system is a force-multiplier.

[mcphage]

I think the purpose is more, "you think that transactions are always atomic, but they might not be, so when you start using a new system, check to make sure". Everybody has a set of assumptions, and those assumptions aren't always true. Sometimes they are. So knowing "here's a place that the assumption is false" is interesting, but not necessarily helpful. Instead, these kinds of lists let you know which of the facts that you know are merely assumptions, so you can investigate if it's true or not in your particular case, and then decide if it matters.

[alganet]

Yep, you are right. Examples would go a long way. Now that I stopped to think about it, once you know these issues by heart, you kind of don't need the checklist anyway.