Wednesday, February 01, 2006

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.

4 comments:

Bill said...

Definite thinker, Phil... I think you've definitely tapped on one of the important characteristics of a successful IT Architect. However I hope it isn't one which is "unrecognized". If it is -- I hope those unaware are reading your blog!

Grady Booch defines some important responsibilities of architects:
- Facilitate communication among team members and resolve conflict
- Along with the project manager, serve as the public persona of the project

These responsibilites require the skill to communicate project details to people in different roles. From a business analyst to a developer to a tester to an executive, the architect must be able to communicate the project/system. Using concise language is critical to accomplishing that.

Sometimes communication varies by the audience, and it needs to. To one person, we may say the application server "talks to" the database server. To another, we may say the application server "uses a TCP/IP connection via port 17001 to access" the database server. To another, we may say the application server "makes SQL calls via JDBC to" the database server. We're using different language, deliberately, similar to using different views (e.g. logical, implementation, physical, etc.) of a software architecture.

But other times it's important to boil down concepts to their most important elements and just "keep it simple". "Bugs decrease with less code." "Brevity is the soul of wit." As the "public persona", it's important to be able to explain things in a way everyone can understand -- in a concise manner.

(In a bit of irony, I wonder if the length of my comment decreases its validity... But I'll worry about that on my next flight in coach!)

Axel Magard said...

Hi Philip, this is a great article and a pleasure to read !
I actually think "simplification" is an essential skill for IT architects and others and finding the right names for things is part of it. Today we make too many things unnecessarily complex and we need people to simplify.
Some years ago a manager told me that my problem would be to make things too simple and I told him that this is not my problem but my strength.
How many complex systems do we design which nobody really likes to use ? How many presentations do we give to customers and they do not understand a word ? How many acronyms and buzz-words do we create every day to even more confuse ourself and the rest of the world ? How may hours do we sit in meetings or conference calls and have no idea what is talked about ? How many hours do we spend cycling around a problem without being able to simply name it ? How much time do we waste because our communication is too artificial, too complex to be effective ? How much time do we waste to search for words we believe might sound more professional instead of using the first word coming into our mind which is most probably the word everyone else would understand right away ?
You brought up a very interesting subject indeed !

Philip Hartman said...

Axel,

You may be on to something. Great names help make concepts simpler.

Philip Hartman said...

Bill,

Thanks for your comments. Your quotes from Grady Booch are great!

I hope the unaware are reading too. Please stop by again.