Monday, March 5, 2012

Anachronistic Derogation

English is my second language. As I learn new words and phrases, I simultaneously try to understand their history and etymological evolution as well. I am always happy to learn new meanings of familiar terms.

The other day, while facilitating a workshop, I used the metaphor "to call a spade a spade" in the context of a software practice. The subject under discussion was technical and my use of the phrase was in no way directed towards any human being or groups of human beings: I was addressing an inanimate technological practice. I don't think the phrase distracted me (or my audience) from the point I was trying to make, because the discussion continued on without being derailed.

In the ensuing break, my co-facilitator told me that the phrase had its origins in a racial slur against African Americans. I was taken aback since I had no idea that was the case. I thanked him for bringing this sorry history to my knowledge and privately resolved to not use the phrase in future.

However, something didn't sit well with me: I remembered reading the phrase in old texts, texts of English (as opposed to American) origin. I had some vague recollections from grade school about the phrase being a metaphorical translation from ancient languages. I know reading Wikipedia doesn't constitute research, however it's entry [1] agreed with my recollections: the phrase acquired negative connotations much later than it was coined. It had been used for generations without any racial overtones, until an unfortunate homonymic alliance with a racial epithet made it unpalatable.

I have run across other phrases that have been assigned a racial etymology retroactively: "chink in one's armor" comes to mind. As I understand, there was an incident recently where a journalist was fired because of his injudicious use of that phrase [2] in an online article.

As someone who has witnessed racist epithets first-hand (both applied to myself and to others within my earshot), I have an above-adequate aversion to such phrases. I am very happy when people object to the use of inherently and irrevocably derogatory words and phrases, even when the speaker might have done so in ignorance. I am equally happy when terms that are defamatory in their origin -- like "Paki", which applies to me -- is reclaimed by those towards whom it was directed as a form of insouciant and irrepressible pride.

However, I am troubled when a term that had no racial or derogatory overtones in its genesis, a term that has been used for decades or even centuries in a neutral way, suddenly acquires an anachronistic "history" of being a racially motivated term. It is history-rewriting of a rather egregious form. It is one thing for a word to evolve and acquire new meanings -- a living language should always exhibit this trait as a testament to the inquisitiveness and tolerance of its adherents -- however the reattribution of a word's or phrase's origins is a foul practice, on par with cheating and swindling.

I'll probably shy away from using the phrase my colleague asked me to avoid. However, I have enough spunk to use it one last time: rewriting a word's etymological history is just plain lying; to call it anything else is to avoid calling a spade a spade.


Friday, February 10, 2012

After walking for several miles through St. Louis

The river was first, I'm sure
Meandering through the plain.
Later, I surmise -- what history I know --
The cowpaths now paved into relative permanence.
A crooked bridge: angular, not curved.
As if eager to span the river below;
The shortest path may not be a straight line
When you're bisecting a fractal curve.
Then the shiny monument:
The upturned necklace hung over the city-gate.
Like a welcoming garland to travelers westbound.
But like an inverted horseshoe,
Imbued with ill-luck
For unsuspecting premonitionists.

And lately, my instep arch,
That not only keeps the ache
(Like the bard of Boston said),
But also leaves a curved footprint;
Another ephemeral contribution
To the arch-city's history.

Thursday, February 3, 2011

Rivulet

Once in an unexpected way
A struggling thought did stray,
Leaving the appointed bounds
It hearkened to sweeter sounds.

A heady yet heedless brook,
Charting a way no one mistook
To be a plausible course
It burbled - spared no remorse.

Weak though it was, it was hard to dam
'Twas not the current, but the sham,
Mocking, random way it swayed;
That stopped its run from being stayed.

It was as if the rivulet
Knew what fate it would have met
And with an unseen force
Made its way from its source.

Downstream and upstream!
The thought was itself a dream
Unrestrained by physical law,
It charted a course no one saw.

But dreams have their own laws
As fragile as a dam of straws.
They can not sustain the gales
That pushing reality entails.

The brook seeped in the land --
It could not meet its own demand.
The blazing light of reality
Robbed it of all it could be.

But in the dry sandbed of time
You may yet spot its prime.
The thought is long bygone,
Its dry course still holds strong.

Memories

Furrows of my mind,
Lying straight as strings,
In which I sow keenly
Memories of you with me.
Bygone and happy things.

I nurture them with love;
Salt-water do they drink.
I keep them from the frost,
For they must not be lost --
They are my only links.

The seasons, they pass by
Each with its own trail
Of happiness and woe;
But my memories do not grow.
They only grow frail.

Lord, when shall I reap
Fruits of years long past?
Shall I even live to see
Just one grow into a tree --
How long will it all last?

Later, I realized;
Much late, too late, indeed;
Memories ought not to be sowed.
From them, nothing is owed,
For the tree lies all in the seed!

Monday, May 10, 2010

Trust but verify is no trust

"Trust but verify" is a phrase made popular by President Reagan. He didn't invent it, yet his use of it in the context of US-Soviet relations made it an oft-quoted maxim.

Logically, the phrase means "don't trust". It can be proven rather simply.

Let "p" be a statement made by someone who you treat with the "trust, but verify" dictum.

Either p is true or ^p is true.

Let's say you verify p independently and find it to be true. At which point you believe p. In this case it is clear that your belief is based not on the original assertion of p but your independent verification of it. You believe "p is true" only after and only because of your verification; it has nothing to do with your trust in that person. Hence in this case, trust doesn't exist.

In the other case, you verify p independently and find it to be false. At this point, you have reasons to believe that ^p is true (through your independent verification) or that p is true (through the assertion of the one who you "trust"). If and only if you choose to believe p in this case, can we truly say you have any degree of "trust"; if you believe ^p, trust doesn't exist.

So the only scenario where we may say that trust exists between two parties is when one of them makes a statement that the other party believes despite there being independent evidence to the contrary.

The question is: when we verify facts independently and they appear to be contrary to the assertion of the one we "trust", are we more inclined to believe the assertion or our findings? My assertion is that we would be much more likely to believe the facts as revealed by our findings; if for no other reason than the expense (time, money) incurred by us is quite compelling. Also, it would be difficult to justify to ourselves that our dearly-held verification process could be wrong and its results could be discarded on occasion.

"Trust but verify" is thinly-veneered, platitudinous nonsense for "don't trust". Trust me on that!

Saturday, August 1, 2009

Money Makers and Money Counters

I like working as a software consultant. I meet new people from varied domains of knowledge and I get to work with several technologies. I am able to learn new things continually; and boredom is an unfamiliar, unacquainted stranger.

However, there is one aspect of being a consultant that I don't like one bit: accounting for my time and expenses. As a consultant, I'm invariably asked to keep a running total of time and expenses in two (and often more) disparate, unconnected software systems. One is maintained by my employer, the other(s) by my host organization.

Of course, entering data about hours worked and dollars spent in multiple systems as a violation of the DRY principle is antithetical to my professional practices. But even if I had to enter time in only one system, I would find that only slightly less unsavory. And that's the distinction I want to draw in this article.

I like to think of myself as a Money Maker - I like to maximize the business value of people's activities. I strive to inject automation, simplicity, robustness, reliability and other tenets of good design that maximize the value of the tasks people do in their daily professional lives.

I know that other colleagues of mine like to keep track of wealth - I use the term Money Counters for them. They are good at auditing, tallying, arranging, allocating and distributing wealth. I admire them, but I know I am not one of them.

I hasten to add that my classification is neither hierarchical nor a source of pride or denigration. I don't think it's "better" to be a Money Maker or a Money Counter. I do know that most people I'm familiar with vastly prefer one activity to the other for themselves.

I further know that rather than classifying others according to this non-absolute division, it's more important for me to know where my own preferences lie. This allows me to work to my strengths and seek the support of others to overcome my weaknesses.

Monday, June 1, 2009

Embarrassing Acronym

Acronyms abound in my line of work. So much so that we don't smirk but often groan when someone mentions the self-referential initialism TLA. These abbreviations are meant to make conversation easier to conduct by creating nouns [1] from long phrases. Often, however, their brevity does not compensate for the obfuscation they create [2]. Once in a while, an abbreviation can cross the border from the annoying to the embarrassing. 

On a recent project, my colleague Steven "Doc" List spotted the humor (perhaps unintended) in a project named "BO Cleansing". BO stood for Business Objects, not Body Odor. 

Of course, most people would catch deeply embarrassing or offensive accidental acronyms before they become an Internet joke like [WARNING: strong language in linked document] this one. However, the occasional slip in allowing an inadvertently funny acronym may be enough to make a mockery out of an otherwise serious subject. 

Here are a few embarrassing acronyms (or similar) I've run across in my career:
  • The IBM Websphere Application Server stores some authentication information in a file named WebAS by default. On more than one project, I've heard hushed references to this file as "the Web with the big AS"
  • Borland's C++ Builder had files of type Project Description Language, with the extension PDL − which some some people pronounced as "pedal". If you said "I need a PDL file" quickly, you were bound to get a few giggles and few "ahems". 
  • In many demo projects, the names "fubar" and "snafu" are considered par for the course − until you run into a situation where you have to expand these acronyms into their full phrases.
I have no problem with injecting some levity into everyday work and an apt (or even funny) acronym is a good way of doing that. However, the case of the accidentally embarrassing acronym is quite a different story. 


[1] Or verbs: I have been told that "TDD-ed" is the past/past participle and "TDD-ing" is the present participle of TDD.
[2] I've heard people say (and write!) "ETL the OSB data from GAPROD to TSPROD"