Wednesday, April 22, 2020

Maps, Territory, and Naming in our Software


I recently started reading through Kai Wai Cheung's book on "Naming things," in software development and wrote about why I am interested here in my blog.  I also gave this keynote presentation about inferring user identity a while back where I touched lightly and obliquely on this topic of naming variables and database fields with words such as "visitor" instead of customer to account for bots.  I have recently come across a few situations at work where the mental models of my peers are unrelated to the reality we are seeing. The problem is amplified by the names we attach to the entities we discuss, and the lack of shared meaning (common understanding ) among the people discussing "the territory" of our business phenomenon.

The Map Territory relation
From wikipedia
The map–territory relation describes the relationship between an object and a representation of that object, as in the relation between a geographical territory and a map of it."

In the example from my presentation on inferring a person's identity from their behaviors instead of relying on their cookies, sign-in credentials, what they have, what they know, etc. I recommend that database fields, object names, code variables, and other naming of the entity connecting to your web site be labeled "visitor" instead of "user."  And instead of confusing an account with a single, registered "user" we should carefully name the entity an account.  After all, one person or bot may have many accounts, and one "household," "shared," or "company" account may have many different people or programs operating using that account.

The same many-to-many mappings exist for devices to humans (or bots) and most other identifiers.

Cause - Effect Confusion
Among the many, odd business situations I encounter at work, one of the most frustrating is confusion and frequent self-deception about causation, correlation, bias, and the prediction afforded by evidence-based science.  I wrote about one example relating to agile practice a while ago. The "cargo cult" practice or belief that when B follows A that A causes B, or in Latin: post hoc, ergo propter hoc is much worse than one would expect in business.

As always, I welcome your comments, good, bad, and non-sequitor.

No comments: