Avoiding Technical Antenantiosis

Writing good code and creating solutions that are easy to configure and manage requires attention to several different details. Ironically, when it comes to simple binary settings and variables, it's actually easier to run afoul of poor naming choices than you might initially think. When this happens, it leads to what I call technical antenantiosis. Antenantiosis refers to a rhetorical device that commonly occurs in ancient Semitic texts as a specialized form of negation that's used to emphasize a positive.

Antenantiosis As a Rhetorical Mechanism

Throughout my college career I pursued a double major in anthropology and near Eastern studies, which means that I've spent a decent amount of time studying how grammar works in different languages. Accordingly, one of my favorite jokes is where a linguistics professor explains, "In English, a double-negative can represent a positive -- but in some languages, such as Russian or Spanish, a double-negative remains negative. No language, however, lets a double-positive become a negative." A student sarcastically replies, "Yeah, right."

I think this joke is great because it points out how complex negation and simple logic can be. It also helps introduce antenantiosis, which is a technique for expressing the importance of a given thought or concept by stating its opposite -- for example, saying "nothing is impossible" to express the exact opposite that "anything is possible." A more archaic example would be, "Despise not the promises of your fathers" to express that not only should these promises not be held in contempt, but also that they should be cherished.

How Does Antenantiosis Apply to Technology or Development?

Given that antenantiosis is all about purposefully negating concepts to accentuate a positive point, it stands to reason that this rhetorical technique isn't the tersest means for communicating simple options or settings. As such, the last place you would want to run into purposeful negation would be when you're troubleshooting code or trying to determine which security setting to enable or disable within a mission-critical application.

An example is when a DBA is rebuilding SQL Server indexes and an advanced option that only very experienced DBAs should use prevents locks from taking place at row level via the ALLOW_ROW_LOCKS switch (which defaults to ON). For this particular option, it's drop-dead simple to see whether row-locking is being allowed or disallowed when looking at how the switch is set. However, index rebuilds lets a STATISTICS_NORECOMPUTE option (which defaults to OFF) be used to prevent SQL Server from refreshing statistics that are updating when an index is rebuilt. In my experience, it's always a bit more difficult to logically ascertain what's being set when a setting option includes some sort of negation in the name of the option or variable, which is something that you'll commonly see when dealing with security.

Binary Options Are Much More Difficult than You Might Originally Assume

On the surface, it's easy to think that binary options aren't that difficult to figure out. However, in reality binary options can be a pain. For example, dual-sided DVDs and USB plugs usually have marking on one of the sides that says "Wide Screen." The problem is in determining whether that side should be face down toward the laser or whether it should be face up. I rarely get this correct, no matter which logical path I go down. I always seem to have to eject and reload the disc, which is a very painful first-world problem that I must endure.

The same thing goes for standard USB connectors. The typical joke is that you always have a 50 percent chance of getting that connection wrong the first time you try it. My odds always seem much lower, mostly because I typically try to fit the plug in, worry that I've gotten it upside-down, and flip it around out of a fear of forcing it into the connection, only to realize that I actually had it correct the first time. In both cases, there are only two options but getting them right is actually more difficult than it would seem at first blush.

Avoiding Antenantiosis in Development

To avoid situations in which binary options can cause problems in your code or let administrators or end users easily misconfigure your solutions, try to avoid antenantiosis (i.e., negation for the purpose of being explicit). As I alluded to, antenantiosis is more common for situations in which security options or features are being defined. This is especially true when certain types of behaviors are being blocked to increase default security and in scenarios in which enabling these features might put users at risk. For example, if you have a feature called DISALLOW_SOMETHING_SCARY that's set to ON by default, then it carries the connotation that admins or users can turn that feature to OFF if they'd like to enable the feature. However, it also comes at the price of facilitating antenantiosis, which means that it's a lot more difficult to understand than an option of ALLOW_SOMETHING_SCARY, which defaults to OFF. In either case, you're dealing with simple binary options -- but one option is drastically more readable, understandable, and manageable than the other.