Abstraction and Naming

I was recently reminded of how I tend to abstract software (one of the reasons I'm an architect).  I was discussing the high level architecture of a product with a client.  We had a sketch on the white board of the various components in the solution and how they interacted.  After I repeatedly spoke of one of these components as the "DOC engine" several times, my colleagues corrected me and told me it should be the "OOC Engine".  Practically the next words out of my mouth were to call that component the "DOC Engine" again.   As I said it again I finally saw the label on the whiteboard that looked like"DOC Engine", which is why I had been repeating it.

At that high level of conversation, the actual words I used to talk about the component were actually rather arbitrary, which is why "DOC Engine" worked just as well for me as "OOC engine".  For that matter "Fred", "Foo" or "Fidazzle" would have worked just as well for me.   It was just a software component with some responsibilities and interactions with other components.  The name was irrelevant.

However, as design advances, names become important.   In one of the earliest projects I worked on as an independent consultant, the developer I was working with named a table "Transmis.dbf" (yes that's a dBASE file name, and yes, it's eight characters).  He called the file "Transmis.dbf" because it contained the set of data that needed to be transmitted for orders.  The file was actually an order detail file; it had one row for every item entered on an order.  I worked for years with that code and every time I had to use the "Transmis.dbf" file I had to do a mental translation between order detail and "Transmis".  Or when I looked for the order detail table and couldn't find it, I eventually remembered it was "Transmis".  Every time.  For years.

So, I do believe that picking the right name is critical and will either help or hinder developers in understanding your system.  But like anything, there's a time to pick the name and it doesn't have to be at the outset.  The right name is a result of understanding the responsibilities of a component, and until you've crisply defined those responsibilities, almost any name will do.  Feel free to use "Fidazzle".