« February 2012 | Main | October 2012 »

May 10, 2012

CONFIDENTIAL (in a web forum?)

This appeared at the end of someone's post on a discussion group in LinkedIn:
CONFIDENTIAL AND ATTORNEY/CLIENT PRIVILEGED: This e-mail and any attachments are confidential, intended for the addressee only and may be attorney/client privileged. If you are not the addressee, then please DO NOT read, copy or distribute the message or any attachment. Please reply to the sender that you received the message in error and delete it. Thank you.
Now, I know that it's not always obvious that your email system is attaching these boilerplate texts to every email you send. So I can forgive the user's carelessness in using email to reply to a discussion group.

But isn't there something the software developers could do to make this less obviously wrong?

I had earlier posted about "Software for Idiots", asking software makers to allow smart users to jump quickly past the step-by-step installation. I said that "How we envision our users defines how we build our software."

So could we understand how our helpful shortcut -- to automatically attach a signature message to every email we send -- can make our user seem ridiculous? And, if we understood that, could we find a way to make this more respectful of how the user presents him/herself?

Some of our software have the specific purpose of presenting our user to others. We don't always know who the other will be, or whether they will be business-like or friend-and-family.

Yes, it would be smart of the user to pay attention to how they use the software, to take the extra care to make sure only appropriate messages are added to our emails. It's not hard to do. But the truth is many users won't take that extra step. More to the point -- that extra step is actually several steps and easy to forget.

A thoughtful software designer might burn a few brain cycles in search of some face-saving, embarrassment-avoiding help for the users.
[ Yahoo! ] options

May 05, 2012

Why "Metaphysics"?

A very short blog entry this time : Read this article: Data Management Is Based on Philosophy, Not Science

My field of study at the university was philosophy (after a couple years of political theory and constitutional democracy). I still keep the works of Aristotle on my shelf. I've always thought philosophy was the perfect way to prepare for a career in information systems. I make that recommendation to parents asking what their computer-savvy child should major in. They always look at me like I've grown an extra eye!

But philosophy is the study of ... well, of everything, and metaphysics is the precursor to philosophy.

Hence -- software metaphysics -- the fundamental thinking that prepares the ground for all software.

Worth a read.
[ Yahoo! ] options

May 01, 2012

The Key is "Just Be Natural"

A questioner asked how to select a natural key in a business data model. In this case, the business is modeling client organizations across international boundaries. He wrote:
In a business data model I was wondering about something like National Registration Number (varies by country), Country, and National Registration Number Qualifier (if there could be multiple registering organizations - which raises other considerations).
A natural key (as opposed to, say, a surrogate key) has the two-fold goal of being (1) unique, and (2) "naturally" memorable. A memorable attribute of a person or an organization is their name, but -- alas -- that is almost never guaranteed to be unique. In a business setting, where the business has control of the organization's name, the name is a much better candidate. However, it's not clear from the question whether the business has control of the name.

It is important to know that the "National Registration Number" is a surrogate, and not a natural key. At least this is so in the United States, where this is the "Federal Employer Identification Number" (EIN) or the "Taxpayer Identification Number" (TIN) -- a number assigned by the Federal government but not indicative of the business itself. Like any surrogate key, the number is arbitrarily assigned and usually forgotten by the business itself. (Technically, the TIN is not guaranteed to be unique either, though in practicality it is.)

My point, I guess, is that the purpose of having a natural key is to simplify look-up -- and typically you are simplifying the look-up of a surrogate key. Within the data model, all relationships are by the surrogate key, a system-defined identifier that is guaranteed to be unique (though not memorable, meaningful or derivable).

So a suitable natural key could be the name of the organization or an organizational identifier, coupled with some geographic qualifier (in the US, the country is not specific enough; many business names are only unique within a state).

But it's important, I think, to keep in mind the reason why a natural key is desired: it is memorable (naturally) and it is unique. That only matters where the user enters into the data model -- it doesn't matter, and shouldn't be used, to navigate relationships within the model.
[ Yahoo! ] options