The Dictionary Test

One of the challenges in software engineering, healthcare standards, or any other similarly complex activity is that all of the good words are already used.  So we have to come up with names for things that identify what it is clearly to readers.  As an engineer I observe that it is not the names that are important, but rather the concepts they encode, and as long as I understand what the thing is, I don't really care what you call it. Names are something for the marketing department to decide, not me.

However, with my consumer hat on, it is very important to me that what you call the thing really describes it, and so I have used what I call the dictionary test to evaluate names.  That test is simply this: If you understand the dictionary terms used in the name of a thing, do you obtain a good understanding of what the thing is.  If not, you've failed the dictionary test.

Standards organizations have a difficult problem, because they often think that they can define what a thing is, give it a name, and make it stick.  Guess what, unless somebody really cares about following the standard, this doesn't work.  If you have to train somebody about the meaning because the name doesn't give it right away, you've put a roadblock in the way of the user of that thing.

Health Information Exchange is a perfect example of both passing and failing the dictionary test.  It passes the dictionary test because as a noun-phrase, or a verb-phrase, it perfectly explains a thing or a process being executed.  It fails because you cannot tell whether the thing being described is a noun or a verb.  It sticks because unlike CHIN, NHIN, HIO or RHIO, (or the various decodes of those acronyms), it really does describe in a very non-technical the thing being described.

So if you find yourself explaining why it is called what it is called, and it isn't too late, pick another name. And if it is, (like UML's Actor), be sure to understand the story behind the name so that people will understand it simply.

   Keith

P.S. As I understand it, Actor was a (mis-)translation from the French term used in some of the original modeling design work, that meant Role.  And Role truly is a better name for actor, because the names of actors in most UML diagrams are in fact, roles played by people or systems.  And once I explain that to a group of non-engineers, the term Actor becomes slightly less scary because I've given them the cognitive link to help them make sense of the term.