Rules of Engagement, Part 1

Topic Drift

Picking an appropriate target is a critical skill.

Bad discussions drift away from the original topic towards well-trodden, hashed-out territory, until they reach the end predicted by Godwin's Law, or the bottom of this post.

So if my posts on Partitions, with a capital P, evoke a response that is all about "eventual consistency," we know exactly where that discussion is going, namely, nowhere interesting. The C-word comes up only once in my first post, on a tangent when describing the backstory for how first-gen NoSQL stores can get away with what they do during partitions, and appears only in a quote from someone else in my second post.

There have been countless religious battles between eventual consistency and stronger consistency models on developer forums, Quora, Reddit, HN, Wikipedia and just about everywhere else imaginable. (Though readers who revisit these discussions will probably be struck by how some of the loudest participants are also some of the least informed and bereft of even the most basic definitions). I have no desire to revisit these tired old arguments.

We all realize that some people like to collect tired old arguments from religious battles and rehash them at the slightest opportunity. This is ok, but supremely boring. Anyone can re-live these discussions by reading the old ones. I will respond and link only to posts which materially advance the debate.

Does Not Follow Fallacy

Bad discussions create noise around a topic without making a logical case.

My point was "X does not necessarily help Y, in fact it can hinder it" where X is a property of a database and Y is a property of an application that uses that database. Specifically, X here is "partition-tolerance," of the database. Surprisingly, Y is also "partition-tolerance," of the application.

So it's confusing when I read a response that says "but, but, but X helps Z."

Undoubtedly. There are lots of applications out there, and one should use a data store that serves the given application well. What is unexpected is that, even when X looks like a strong property on the surface, it may not be a good fit for the application, even when the property Y that the application needs sounds exactly like the property X that the database provides.

Mixing of Colloquial and Technical Terms

Bad discussions mix technical terms, such as the various Consistency incantations, with their colloquial definitions. Worse, they use terms with no definition.

My Consistency Alphabet Soup post, as well as my NoSQL definition post, were made to avoid this kind of mixing and matching that causes people to talk past each other.

Extreme Pedantry

Bad discussions involve a participant who makes crazy, pedantic demands that serve no purpose.

Insisting that I use the word "corpus callosotomy" instead of "lobotomy" makes the entire counter-argument unreadably cringe-worthy. Lobotomy stems from "split-brain operation," a technical term. But even if it did not, the pedantry involved, the need to correct something, anything, at any personal cost, would still induce a cringe.

And no, I will not replace "crazy" in the topic sentence with an official DSM designation (301.7 with a dash of 312.34?).

Emotional Reaction to Objective Reality

"Weak" has a technical meaning. Someone who does not know this meaning is not someone who should be debating its usage.

Bad discussions involve a participant whose responses are driven not by logic fueled with passion, but instead by pure emotion.

"Weak" is a technical term. Sometimes, all else being equal, it means desirable as in "our system makes weak assumptions." Sometimes, all else being equal, it means undesirable as in "eventual consistency provides weak guarantees compared to linearizability."

Somehow, this technical term evokes an emotional reaction from people who do not understand that it is actually value-neutral. If a weak consistency model gets me performance, that would be great (turns out that it does not, but that's a separate issue).

Luckily, most eventual consistency proponents are excellent engineers who understand the strengths and limitations of their consistency model. They will readily admit that EC can yield unexpected behavior. For instance, a developer who increments a value three times can have clients that observe, in order, "1, 2, 1, 2, 1, 2, Does-Not-Exist, 3, 2, 1, 3." EC is technically a weaker consistency model than, say, linearizability, which ensures "1, 2, 3," and nothing on earth can change this fact. The better companies in this space are those that are up-front about these properties.

As a scientist and engineer, I am compelled to use the correct technical terms that correspond to reality. So if I call something "weak," it is not a value judgment. Non-scientists and overly emotional people will have to either learn to speak the technical language, or spend their life seething, needlessly.

Ad Hominems

Bad discussions quickly turn personal.

Most people I know just walk away from any technical discussion involving ad hominems. The moment the discussion leaves the realm of the technical for the personal, whoever did that not only loses that particular argument, but loses credibility for ever after.

Loaded Pigeonholes

You should see the spin I can put on a baby with my cleats.

Bad discussions paint the other side into a corner that they do not occupy.

This is typically a corner that involves beating wives, drop-kicking babies, or opposing modern version control systems such as git, hg and bzr.

Modern version control tools have absolutely nothing to do with NoSQL. They are examples of applications which achieve partition-tolerance, but the way they do this, with the aid of a "C as in CAP" filesystem and without any help from a partition-tolerant database, is neither here nor there. Bringing them up on the NoSQL side undermines any point one might want to make about the partition-tolerance of first-generation NoSQL databases.

But let's have the record reflect that I love motherhood, apple-pie and git as much as the next person. Perhaps some day I'll master rebase.