Naming Well, an Essential Skill of an I/T Architect

I had a recent experience on my project which caused me to think about the impact of names and the choice of words we make on I/T Architects and the success we have on our projects and in our careers.

We had a production problem that was giving us fits. I came into problem determination somewhat late and was invited to a meeting to discuss the issue. There were error messages in the log and the team was investigating the data associated with the transaction that failed. One developer who had been looking at it for a while said "I don't see a problem... the data looks good." There was then much discussion about what the cause of the problem might be. Someone raised the possibility that perhaps the transaction that threw the error was not the cause of the problem at all. “If the problem was a deadlock on a database record, then the next transaction to try to update the same record would fail.” Without thinking much about it, I threw out the comment "Then the transaction that failed was the victim and not the perpetrator." Another architect on the project then smiled, leaned over, and made an interesting side comment on all this with a comment along the lines of "That's why you're THE architect!"

At first I didn't quite know what he meant. It appeared to be some reference to me being the lead architect. Also something about my casual (casual to me at least) comment had something to do with me getting promoted over time to my position. He and I have a great working relationship I think (tell me if I’m wrong “Z”) and the apparent reference to my rank in the organization made me a little nervous. I didn’t know where this was going and there was still a room full of ears in the room and a couple still on the phone.

Then he let me in on his perspective. He said I had quickly come up with two very descriptive words; "victim" and "perpetrator." His opinion was that my choice of words were immediately understood by all. (My words now.) They provided a "shortcut" for everyone who had not yet realized that the problem might not be with the transaction that threw error messages into the error log. The choice of words allowed all to quickly change gears and consider a new (and perhaps more likely) cause of the problem.

Shortly later I had several hours to think about this while I was captive in a seat in coach as I was flying cross-country. I was, of course, glad my comments and the names I chose were helpful. I wondered to myself at 34,000 feet, “Are the words we choose to name things really that important?” I had a slightly more provocative thought, “Was my ability to choose names for I/T concepts that were quickly understood a major contributor to my success in my career?" Could it be true that the names I have chosen over the years for all those problems, symptoms of problems, objects, attributes, methods, database tables, columns in databases, subsystems, components, use cases, etc. really have been a major productivity boost for me and project my teams? Bored with the SkyMall catalog I continued...

• How many hours of development time have been saved over the years by not having to explain a concept over and over because the name itself helped explain the concept quickly?


• How many painful hours of documentation were avoided?


• How many hours of skill transfer were avoided when new developers joined a project in mid-stream?

Unfortunately, there is no way for me to know but my gut instinct is that the number of hours saved over all the projects and all the team members over all the 20+ years in technology is large. Intuitively, I think it must really be a big deal.

As I found no way to get comfortable in my airline seat in coach so as to get some sleep, I contemplated still more questions. “How do you tell if you're good at it?” After all, nobody goes around saying "I want Phil on my project because he names things well." More likely they say something like "I want Phil on my project because he's been successful before" or "I want Phil on my project because he's up on all the latest technology."

Wait a minute. Keeping up is hard work keeping up and there are only so many hours in the day. Could the real story be that I am successful in spite of being a step behind the latest tech craze because I name better than the ultra-geek who is up on the latest thing? Thankfully, I fell asleep in that uncomfortable seat before this thought went too far.

Now that I’m back home, I guess I have no excuse for continuing to think about this whole “naming thing.” With all the ethnic diversity in the software business, is this an area where aspiring I/T Architects from other cultures (than mine) might have trouble picking the perfect name for others to grasp immediately? My guess is probably "yes" but I'm no cultural anthropologist or cognitive psychologist or anything like that. (Incidentally, my architect-friend who complimented me on my choice of words "victim" and "perpetrator" grew up in Brazil.) If the recipient of my architecture documents is from a different culture than mine, does that make me the one at a disadvantage? Again, my professional instinct says the answer is "yes" but I can’t prove it. Is naming well a skill that almost any technically inclined person can learn? Or is it a gift? Is there a "naming gene" that predisposes me to compete at a higher level in the software business "naming olympics?" Do I name well because of how God wired my brain or because of my unique combination of life experiences? Or both? I wish I knew.

In conclusion, I believe I have convinced myself that “naming well” is indeed an essential but unrecognized skill of an I/T Architect... and I am grateful to have this small advantage to keep me gainfully employed a little longer. :-) I’m not sure I know how to teach someone else to “name well” but I know a good name when I hear it. I invite your comments on this topic.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.